----- Original Message ----- From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@xxxxxxx> To: "ext t.petch" <daedulus@xxxxxxxxxxxxx>; <stbryant@xxxxxxxxx>; "Adrian Farrel" <adrian@xxxxxxxxxxxx> Cc: "iesg" <iesg@xxxxxxxx>; "ietf" <ietf@xxxxxxxx> 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@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