Neil, I have a question for clarification. Have you actually read draft-ietf-mpls-tp-cc-cv-rdi-05.txt? I know you don't like doing this but generally it is considered good form to read something before commenting on it. Thanks, John Sent from my iPhone > -----Original Message----- > From: mpls-bounces@xxxxxxxx [mailto:mpls-bounces@xxxxxxxx] On Behalf Of > neil.2.harrison@xxxxxx > Sent: Friday, July 08, 2011 12:16 AM > To: RCosta@xxxxxxxxxxxxx; david.i.allan@xxxxxxxxxxxx; > stbryant@xxxxxxxxx > Cc: mpls@xxxxxxxx; ietf@xxxxxxxx; ietf-announce@xxxxxxxx > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > Got to say I agree with Rui on much of what he says here. And I > absolutely resonate with his point on the need for simplicity. The > reason OAM needs to be as simple as possible is because it must be > super reliable....we do not want to consciously build in weaknesses, > esp unnecessary ones.... this also implies minimal config. We could > all do better on this. For example: > > - Rui is dead right a CC function is fairly useless, we only need > a CV function...the ATM OAM in I.610 suffers from this problem (and few > others like AIS and the assumed use of request/response MLT to diagnose > leaking/mismerging traffic...request/response OAM won't work with > unidirectional defects). > > - all packet layer networks should not have an AIS OAM > message....very obvious for the cl-ps mode of course. The co-ps mode > is also not like the co-cs mode. One has to consciously manufacture > AIS messages and target them to specific clients in the co-ps > mode....who may have taken action in their own layer network and 'moved > elsewhere' anyway, ie a total waste of time now. AIS is actually > unnecessary wrt providing information anyway, it simply represents an > in-built weakness of just something else to go wrong which itself will > create problems. > > - creating preconfigured TCM sublayers is just asking for trouble > IMO. It is far smarter to simply create a single end-end OAM CV (and > when required PM) flow and tap this off at intermediate nodes on the > *rare* occasions one wants to do. > > regards, Neil > > This email contains BT information, which may be privileged or > confidential. > It's meant only for the individual(s) or entity named above. If you're > not the intended > recipient, note that disclosing, copying, distributing or using this > information > is prohibited. If you've received this email in error, please let me > know immediately > on the email address above. Thank you. > We monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > > > > > > > > > -----Original Message----- > > From: mpls-bounces@xxxxxxxx [mailto:mpls-bounces@xxxxxxxx] On Behalf > Of > > Rui Costa > > Sent: 08 July 2011 01:15 > > To: David Allan I; Stewart Bryant > > Cc: ietf@xxxxxxxx; IETF-Announce; mpls@xxxxxxxx > > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > > (Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > David, > > > > Reading something, keeping it on record, without effect in the draft > > and "ignoring comments" have IMHO similar outcomes. As author of the > > draft you are free to do it. These standards have a great impact in > our > > work, so i'm also free to write what i did. > > > > > > > > > > Stewart, > > > > My technical concerns regarding this draft were expressed... > > ...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i > > believe); > > ...in operators' meetings' that took place during ITU-T's Feb/2011 > > plenary meeting; > > ...in a comparison session that took place during that same ITU-T > > meeting. > > Some: > > > > CC/CV > > I don't understand the need for 2 types of packets: a single type > > allows CC; mismatching identifiers in the same CC packets allow CV. > > Besides adding complexity, we whether always activate both or > > potentiate undetected mismerges. > > (BTW: can't understand how we propose one ACH codepoint to CC, > another > > for CV, [counting other drafts, another for frame loss ...] but don't > > consider assigning 1 single ACH protocol identifier codepoint as > > requested by ITU-T) > > > > Uni P2P / P2MP > > I can't see how BFD will support unidir and hence P2MP other than... > > > > ...eliminating the session "state variable" (down, init, up), aiming > > just the state variables we really need, bringing us to something > > similar to 1731, eventually with other bits on the wire or... > > ...using IP to create the reverse way, which we cannot assume per > > requirements; > > Will we create a complete different tool for that? > > (BFD's B="bidirectional") > > > > Provisioning list > > This is an MPLS profile/subset (and i heard) achievable through a > > particular configuration. So, i expect each draft-ietf-mpls-TP-* to > > focus on that profile/configuration. However, i keep seeing > references > > f.i. to IP encapsulations unexpected under TP's OAM. > > I don't thus understand what the aim is: do we expect this in TP, are > > we talking about MPLS in general?... The TP profile is never quite > > delimited. > > Does chapter 4 contain ALL the configurable parameters list agreed to > > provide in the comparison session? > > > > Backwards compatibility > > This was the main argument risen to ground MPLS-TP OAM on BFD. It's > not > > a better argument than grounding MPLS-TP OAM on 1731 due to its ETH > > deployment plus coherence with SDH, OTN, as defended by ITU-T. > > For reasons like the above, however, MPLS-TP BFD won't be backwards > > compatible with previous BFD (even considering just CC/CV). They > don't > > even share the same codepoint. > > > > Simplicity > > Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is > > simpler: in each flow, a standard defined nr of constant heartbeat > > signals (with standard constant or provisioned period - no > > auto/negotiated -) means OK. A standard defined number of misses > means > > lost Rx connection. An RDI, the only articulation between Rx and Tx > > flows, meaningful in bidirectional applications, allows each pear to > > identify Tx problems. > > This OAM simplicity is the key for reliable fail finger pointing, > > performance reports and protection. Also to allow scaling, more > > implementation opportunities/manufacturers, which is valuable for > > operators. > > > > > > IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more > > difficult to tell which is which. > > > > Regards, > > Rui > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > From: David Allan I [mailto:david.i.allan@xxxxxxxxxxxx] > > Sent: quarta-feira, 6 de Julho de 2011 19:25 > > To: erminio.ottone_69@xxxxxxxxx; Rui Costa; ietf@xxxxxxxx; IETF- > > Announce > > Cc: mpls@xxxxxxxx > > Subject: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > > 05.txt> (Proactive Connectivity Verification, Continuity Check and > > Remote Defect indication for MPLS Transport Profile) to Proposed > > Standard > > > > Hi Erminio: > > > > <snipped> > > >Several service providers regarded this draft as not meeting their > > >transport networks' needs. > > > > E> This is a true statement: the solution in this draft is useless > for > > many MPLS- TP deployments. > > > > The two statements do not necessarily follow. > > > > What we established during discussions at the SG15 plenary in > February > > was that the issue some service providers had was that the IETF BFD > > solution exceeded their requirements in that there was additional > > functionality they did not see a need for, and that they considered > any > > additional functionality parasitic. > > > > However this is a consequence of adapting an existing technology to a > > new application. I do not see any way around that. And the entire > joint > > project was based on the premise of engineering re-use not greenfield > > design. That is what it said on the tin up front, and IMO why when > the > > IETF started down this path packet transport transitioned from being > a > > minority sport to mainstream, so it is a bit late to cry foul.... > > > > My 2 cents > > Dave > > > > > > > > > > -----Original Message----- > > From: David Allan I [mailto:david.i.allan@xxxxxxxxxxxx] > > Sent: quarta-feira, 6 de Julho de 2011 18:36 > > To: erminio.ottone_69@xxxxxxxxx; loa@xxxxx; Rui Costa > > Cc: mpls@xxxxxxxx; ietf@xxxxxxxx; IETF-Announce > > Subject: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > > 05.txt> (Proactive Connectivity Verification, Continuity Check and > > Remote Defect indication for MPLS Transport Profile) to Proposed > > Standard > > > > Hi Erminio: > > > > Two of the three document editors were present at SG15 plenary in > > February where the comments originated. The revised meeting schedule > > resulted in a day spent going through the document with the editors. > > IMO there were lots of discussion and legitimate issues with the > > document identified and corrected so it was a useful session. The > > liaison of same was in many ways *after the fact*. > > > > Cheers > > Dave > > > > > > > > > > -----Original Message----- > > From: erminio.ottone_69@xxxxxxxxx > [mailto:erminio.ottone_69@xxxxxxxxx] > > Sent: quarta-feira, 6 de Julho de 2011 18:34 > > To: Rui Costa; ietf@xxxxxxxx; IETF-Announce > > Cc: mpls@xxxxxxxx > > Subject: R: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > 05.txt> > > (Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > The way this draft has been developed is a bit strange. > > > > The poll for its adoption as a WG document was halted by the MPLS WG > > chair > > because "it is not possible to judge consensus": > > > > http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html > > > > The lack of consensus was motivated by serious technical concerns > > raised by > > several transport experts during the poll. > > > > Nevertheless the MPLS WG chair decided to adopt the draft as a WG > > document: > > > > http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html > > > > After several WG revisions and WG LCs, the technical issues have not > > been > > resolved. > > > > >Several service providers regarded this draft as not meeting their > > transport > > networks' needs. > > > > This is a true statement: the solution in this draft is useless for > > many MPLS- > > TP deployments. > > > > > > -----Original Message----- > > From: erminio.ottone_69@xxxxxxxxx > [mailto:erminio.ottone_69@xxxxxxxxx] > > Sent: quarta-feira, 6 de Julho de 2011 18:26 > > To: loa@xxxxx; Rui Costa > > Cc: mpls@xxxxxxxx; ietf@xxxxxxxx; IETF-Announce > > Subject: R: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > 05.txt> > > (Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > > Version -04 of the document was published June 28th. > > > > > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > > > June 29th. > > > > > > > So when the WG LC to confirm the LC comment resolution has been > > launched? > > > > The proto write-up says: > > > > It has also passed a working roup call to verify that LC > > comments > > were correctly with minor comments. > > > > It also says: > > > > The comments has been > > carefully discussed between the authors and people making > > the > > comments and > > has been resolved. > > > > But it seems that some comments have not been discussed with the > > authors of > > the comments. When ITU-T Q10/15 has been involved in discussing its > > comments? > > > > > > > > > > -----Original Message----- > > From: Loa Andersson [mailto:loa@xxxxx] > > Sent: quarta-feira, 6 de Julho de 2011 16:44 > > To: Rui Costa > > Cc: ietf@xxxxxxxx; IETF-Announce; mpls@xxxxxxxx > > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > > (Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > All, > > > > Since someone has commented about the process used for resolving > > questions on > > draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. > > > > The history of draft-ietf-mpls-tp-cc-cv-rdi working group review > > process is: > > > > On February 3rd 2011 the working group last call was issued > > on version -03 > > > > This was copied to the the Ad Hoc Team List > > and liaised to SG15 also on February 3rd > > > > This working group last call ended om Feb 28 > > > > > > On Feb 28 we also received a liaison with comments from SG15 > > > > > > The authors compiled a list of all comments received as part the > MPLS > > working group last call; these comments - and the intended > resolution > > - > > is included in the meeting minutes from the Prague meeting: > > > > > > http://www.ietf.org/proceedings/80/slides/mpls-9.pdf > > > > > > During the IETF meeting in Prague, we agreed with the BFD working > > group to do a separate working group last callfor the BFD working > > group > > > > The (BFD) working group last call was started on March 30th and ran > > for 13 days. The last call ended on April 11th. > > > > The authors have since worked hard to resolve comments, some > > issue has been brought to the working group mailing list for > > resolution. > > > > Version -04 of the document was published June 28th. > > > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > > June 29th. > > > > The AD review resulted in a "New ID needed" due to mostly editorial > > comments. Version -05 was published on June 29 and the IETF last > call > > started as soon as the new ID was avaialbe. > > > > The current list of Last Call Comments resoltion is also avaiable > at: > > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > > > The list of issues that the authors kept very carefully, shows > > without > > doubt > > that no comments been ignored. > > > > Loa > > mpls wg document shepherd > > > > > > > > > > > > > > > > -----Original Message----- > > From: David Allan I [mailto:david.i.allan@xxxxxxxxxxxx] > > Sent: quarta-feira, 6 de Julho de 2011 14:58 > > To: Rui Costa; ietf@xxxxxxxx; IETF-Announce > > Cc: mpls@xxxxxxxx > > Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > > (Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > Hi Rui: > > > > The comments were not ignored, the resolution of the Q10 comments as > > well as those collected from the MPLS WG was presented at the last > > IETF. My spreadsheet from which that report was generated and has > been > > augmented to include the BFD WG comments is available at > > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > > > So you know... > > Dave > > > > > > -----Original Message----- > > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf > Of > > Rui Costa > > Sent: segunda-feira, 4 de Julho de 2011 23:03 > > To: ietf@xxxxxxxx; IETF-Announce > > Cc: mpls@xxxxxxxx > > Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > > (Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > IMHO and for the record: > > > > ITU-T comments regarding this draft haven't been discussed with ITU-T > > but were simply ignored. No LS describing these comments' resolution > > was sent. > > > > Several service providers regarded this draft as not meeting their > > transport networks' needs. > > > > [The v03 draft was published in Feb and went to WG LC. > > The v04 draft addressing WG LC comments was published on the 28th > June > > (same date as the proto write-up). > > When was the WG LC launched, to verify LC comments resolution?] > > > > Regards, > > Rui > > > > > > -----Original Message----- > > From: mpls-bounces@xxxxxxxx [mailto:mpls-bounces@xxxxxxxx] On Behalf > Of > > The IESG > > Sent: quinta-feira, 30 de Junho de 2011 14:47 > > To: IETF-Announce > > Cc: mpls@xxxxxxxx > > Subject: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > > (Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > > > The IESG has received a request from the Multiprotocol Label > Switching > > WG > > (mpls) to consider the following document: > > - 'Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile' > > <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to > the > > ietf@xxxxxxxx mailing lists by 2011-07-14. Exceptionally, comments > may > > be > > sent to iesg@xxxxxxxx instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > Continuity Check, Proactive Connectivity Verification and Remote > > Defect Indication functionalities are required for MPLS-TP OAM. > > > > Continuity Check monitors the integrity of the continuity of the > > label switched path for any loss of continuity defect. > Connectivity > > verification monitors the integrity of the routing of the label > > switched path between sink and source for any connectivity issues. > > Remote defect indication enables an End Point to report, to its > > associated End Point, a fault or defect condition that it detects > on > > a pseudo wire, label switched path or Section. > > > > This document specifies methods for proactive continuity check, > > continuity verification, and remote defect indication for MPLS-TP > > label switched paths, pseudo wires and Sections using > Bidirectional > > Forwarding Detection. > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > _______________________________________________ > > mpls mailing list > > mpls@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > > Ietf mailing list > > Ietf@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > > mpls mailing list > > mpls@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@xxxxxxxx > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf