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. Best regards, Nurit -----Original Message----- From: ext t.petch [mailto:daedulus@xxxxxxxxxxxxx] Sent: Saturday, December 03, 2011 7:44 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); stbryant@xxxxxxxxx; 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.sprecher@xxxxxxx> To: <stbryant@xxxxxxxxx>; "Adrian Farrel" <adrian@xxxxxxxxxxxx> Cc: <draft-betts-itu-oam-ach-code-point@xxxxxxxxxxxxxx>; <iesg@xxxxxxxx>; <Ietf@xxxxxxxx> 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@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] 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@xxxxxxxxxxxxxx; iesg@xxxxxxxx; > Ietf@xxxxxxxx > 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf