----- Original Message -----
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
<nurit(_dot_)sprecher(_at_)nsn(_dot_)com>
To: "ext t.petch" <daedulus(_at_)btconnect(_dot_)com>;
<stbryant(_at_)cisco(_dot_)com>; "Adrian
Farrel" <adrian(_at_)olddog(_dot_)co(_dot_)uk>
Cc: "iesg" <iesg(_at_)ietf(_dot_)org>; "ietf" <ietf(_at_)ietf(_dot_)org>
Sent: Saturday, December 03, 2011 8:08 PM
Tom hi,
If this is Ethernet OAM delivered *transparently* over MPLS-TP networks,
then there is *no* need for a code point, they can simply use PWs.
If this is a solution aims to provide an alternative OAM solution for
MPLS-TP networks, and it is based on G.8110.1 and G.8110, and uses the
MPLS EtherType, then it is part of MPLS and MPLS-TP.
I believe it is the second case, therefore it requires the MPLS review
and a follow-up of the MPLS change process.
<tp>
Nurit
Yes, I think that it is more along the lines of the second case, an alternative
OAM solution, but it is the status of G.8113.1 that is in question, with Russ
saying that it cannot be part of MPLS-TP!
ITU-T are actively removing references thereto as in
the .pdf's that the ITU-T have made available to us, URI in the e-mail
from Russ, one of which says
<quote>
From: Johnson, Malcolm Sent: 01 December 2011 10:27 To: 'Russ Housley' Subject:
RE: MPLS
Dear Russ
..
(2) I attached a contribution which proposes amendments to the determined text
in COM15-R22. This includes the title change and makes changes to the
terminology throughout the document. What had previously been called "MPLS-TP
OAM" is now never referred to as such, but simply as "OAM" or "data-plane OAM".
As you can see there is a willingness to satisfy all the IETF concerns but if
there is still something else in the body of the draft Recommendation that
causes concern could you please specify what exactly it is so it can be
addressed?
</quote>
So my take is that the I-D we have needs review as specified in RFC4929, and the
IESG may well
decide that that involves review on the MPLS list, but I remain unconvinced that
that
makes in part of MPLS-TP; MPLS-TP has its OAM and does not need another one,
but some participants in the ITU-T do want another, 'not-MPLS-TP' OAM, and for
that, have requested a code point. Obviously, this needs further discussion on
a suitable list
which we will doubtless engage in before too long.
Incidentally, has G.8113 been liaised to the MPLS WG? If so, I might have
missed that.
Tom Petch
</tp>
Best regards,
Nurit
-----Original Message-----
From: ext t.petch [mailto:daedulus(_at_)btconnect(_dot_)com]
Sent: Saturday, December 03, 2011 7:44 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); stbryant(_at_)cisco(_dot_)com;
Adrian
Farrel
Cc: iesg; ietf
Subject: Re: Request to publish
draft-betts-itu-oam-ach-code-point-01.txt
----- Original Message -----
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
<nurit(_dot_)sprecher(_at_)nsn(_dot_)com>
To: <stbryant(_at_)cisco(_dot_)com>; "Adrian Farrel"
<adrian(_at_)olddog(_dot_)co(_dot_)uk>
Cc: <draft-betts-itu-oam-ach-code-point(_at_)tools(_dot_)ietf(_dot_)org>;
<iesg(_at_)ietf(_dot_)org>;
<Ietf(_at_)ietf(_dot_)org>
Sent: Saturday, December 03, 2011 5:06 PM
Hi,
I fully support Stewart!
G.8113.1 proposes a OAM solution for MPLS-TP networks.
It uses the MPLS EtherType (when transmitted inband and getting the
same
treatment as the data traffic).
The document is built on G.8110.1 (MPLS-TP architecture) which refers
to
G.8110 (MPLS architecture), and G.8110.1 refers to G.8113.1 back...
This makes it part of MPLS and MPLS-TP.
Nurit and others,
I would commend to you the e-mail that Russ posted here 30Nov2011 in
which he
says, to Malcolm Johnson, Director of the ITU Telecommunication
Standardization
Bureau,
IETF consensus continues to be required to allocate the code point.
My
experience leads me to believe that careful clarity about the proposed
content
changes to G.8113.1, as well as specific clarity that G.8113.1 is not
part of
MPLS and MPLS-TP, will aid in achieving such a consensus. The current
situation
has engendered quite a bit of ambiguity in wording which, in my
experience, will
not produce IETF consensus.
so claiming what is and is not part of MPLS-TP calls for some thought.
My interpretation is that this is not part of MPLS-TP, but that the code
point
should be allocated in accordance with RFC4929 which, as I pointed out
on the
MPLS list, does not require a standards track RFC and requires review by
what
the IESG considers suitable, which could, or could not, include the MPLS
list;
but the starting point should be the prior art which Russ has provided
us with.
The deadline would appear to be 12Jan2012 which Malcolm and Huub would
appear to have provided us with the wherewithall to meet.
Tom Petch
And it should be reviewed by the MPLS WG.
Best regards,
Nurit
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf
Of
ext Stewart Bryant
Sent: Friday, December 02, 2011 1:55 PM
To: Adrian Farrel
Cc: draft-betts-itu-oam-ach-code-point(_at_)tools(_dot_)ietf(_dot_)org;
iesg(_at_)ietf(_dot_)org;
Ietf(_at_)ietf(_dot_)org
Subject: Re: Request to publish
draft-betts-itu-oam-ach-code-point-01.txt
Adrian
"It is the opinion of the document shepherd that discussion of
this document on the working group lists would be a distraction
from the technical protocol work that the working groups
need to do."
I disagree with the document shepherd in his evaluation.
The draft clearly sets out to enable the standardization
of an additional OAM for MPLS, and as such the MPLS WG
need to review the document and its references to
determine the consequences of the technology being
deployed.
Furthermore, all MPLS documents that have so far requested
ACH codepoints have I believe been standards track. Why
is this not also a standards track document?
Stewart
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf