Neil, AIS and CC are ITU requirements but I personally agree with you regarding their utility. TCM is an ITU concept that doesn't really apply in an MPLS context because of the way the label stack works, and as I have told you before, the tap-off function you mention is sensible but it is strictly an implementation issue - no protocol work is required. Thanks, John Sent from my iPhone > -----Original Message----- > From: neil.2.harrison@xxxxxx [mailto:neil.2.harrison@xxxxxx] > Sent: Friday, July 08, 2011 6:37 AM > To: John E Drake; RCosta@xxxxxxxxxxxxx; david.i.allan@xxxxxxxxxxxx; > stbryant@xxxxxxxxx > Cc: mpls@xxxxxxxx; ietf@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 > > Not recently John. But my comments are general and not specific to > this draft. But it seems you are implying that the draft recognises my > points. If so I will look forward to reading it later today when I get > chance and seeing AIS deprecated, TCM deprecated, CC functions > deprecated, ability to tap off end-end CV/PM flows at intermediate > nodes. > > 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: John E Drake [mailto:jdrake@xxxxxxxxxxx] > > Sent: 08 July 2011 14:26 > > To: Harrison,N,Neil,DKQ7 R; 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 > > > > 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