Inline <tp> Tom Petch From: mpls-bounces@xxxxxxxx [mailto:mpls-bounces@xxxxxxxx] On Behalf Of ext Thomas Nadeau Sent: Thursday, January 12, 2012 10:30 PM To: John E Drake Cc: mpls@xxxxxxxx; draft-betts-itu-oam-ach-code-point@xxxxxxxxxxxxxx; ietf@xxxxxxxx; ietf-bounces@xxxxxxxx On Jan 12, 2012, at 3:18 PM, John E Drake wrote: Snipped, comments inline. 3. There seems to be quite a feeling on the mailing lists that this document should be run through the MPLS working group. The write-up makes a case for progressing it as AD sponsored. As far as I can see, the main assertions to answer are as follows. Do you have a view on these points before I make a decision on what to do? a. This is a proposal to use an MPLS code point and so is part of MPLS by definition. b. The type of network being managed by the OAM described in G.8113.1 is an MPLS network. Therefore, this is clearly relevant to the MPLS working . Do you object to this going through the MPLS on principle, or were you just hoping to save the WG the work? If the latter, and if the WG wants to look at the draft, the easiest approach seems to be to redirect the work to the working group. [MB] G.8113.1 supports a subset of the functions defined in draft-bhh-mpls-tp-oam-y1731-08. The -00 version was posted in March 2009, the draft was presented at several meetings in 2009 and early 2010 and had extensive discussion on the MPLS mailing list. However, the MPLS WG have, by rough consensus, adopted a different approach. Therefore, further review by the MPLS WG is of little value. [JD] Um, I don't think so. Since, as you state above, G.8113.1 is effectively draft-bhh and since draft-bhh was explicitly rejected by the MPLS WG, your draft, which requests a code point for G.8113.1, is basically an attempt to subvert the decision by the MPLS WG to reject draft-bhh by attempting to bypass the WG with an individual submission. So, I think it is clear that your draft belongs in the MPLS WG. <tp> This I think is the danger of having the MPLS WG review the document. draft-bhh was rejected by the MPLS WG and that is history. Another SDO wants to standardise the technology and, while the IETF may think that that is the wrong approach, that is not our decision. We do however lay claim to control of the code points which would make this technology easier to deploy and that is what this I-D requests. Unless there is some inherent problem in having a code point that invokes a different technology, then there is no reason why we should reject this reasonable request. The risk is that the request for a code point will degenerate into a draft-bhh, now in its G. form, bashing exercise, which can have no positive outcome. We have already decided that draft-bhh is not something we want to standardise, we have already said that having two competing standards is not a good idea (which the current draft recognises); allocating a code point does no more than let the market place decide which approach is better. Tom Petch Incidentally, the MPLS/GMPLS change process was put in place in reaction to the publication of another individual submission, RFC3474, which was completely non-interoperable with standard RSVP, a surprisingly similar situation. Well said John. I couldn't have put it any better myself, and so agree with that statement %100. --Tom _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf