Excellent...well done Adrian! Thanks Dave for the info. Have a nice one yourself.... regards, Neil > -----Original Message----- > From: David Allan I [mailto:david.i.allan@xxxxxxxxxxxx] > Sent: 08 July 2011 17:42 > To: Harrison,N,Neil,DKQ7 R; tnadeau@xxxxxxxxxxxxxxx > Cc: RCosta@xxxxxxxxxxxxx; stbryant@xxxxxxxxx; 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 > > Hi Neil: > > As a result of Adrians AD review, some text to that effect was added to > the Security Considerations section. > > Have a good weekend > Dave > > -----Original Message----- > From: neil.2.harrison@xxxxxx [mailto:neil.2.harrison@xxxxxx] > Sent: Friday, July 08, 2011 9:40 AM > To: David Allan I; tnadeau@xxxxxxxxxxxxxxx > Cc: RCosta@xxxxxxxxxxxxx; stbryant@xxxxxxxxx; 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 > > Thanks Dave. If we don't have this (ie CV function on all > connections/LSPs) then there is potential security risk wrt leaking > traffic. Note that besides trad nested sublayered LSPs in the same > layer network this also applies to nested LSPs belonging to different > MPLS-TP layer networks (may be same or different party ownership). > This point about the OAM CV function also ought to be captured in any > security drafts. > > regards, Neil > > > -----Original Message----- > > From: David Allan I [mailto:david.i.allan@xxxxxxxxxxxx] > > Sent: 08 July 2011 17:30 > > To: Thomas Nadeau; Harrison,N,Neil,DKQ7 R > > Cc: RCosta@xxxxxxxxxxxxx; stbryant@xxxxxxxxx; 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 > > > > I think there is some confusion here.... > > > > The only CC in isolation in the draft is the option to use RFC 5885. > > Which then is a network design issue. > > > > Draft cc-cv-rdi used by itself is CV always on. It is just not EVERY > > PDU that requires CV processing so there are CC and CV PDUs > > interleaved. Mis-connectivity detection is network wide and fairly > > authoritative (unless we are discussing a mode of failure in which > > only "some" packets leak, which means even an always on CV may not be > > so unlucky as to leak and be detected). > > > > So I think we are in agreement on that front... > > Dave > > > > > > > > -----Original Message----- > > From: Thomas Nadeau [mailto:tnadeau@xxxxxxxxxxxxxxx] > > Sent: Friday, July 08, 2011 8:27 AM > > To: neil.2.harrison@xxxxxx > > Cc: RCosta@xxxxxxxxxxxxx; David Allan I; stbryant@xxxxxxxxx; > > 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 > > > > > > On Jul 8, 2011, at 3:15 AM, <neil.2.harrison@xxxxxx> wrote: > > > > > 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). > > > > While you are entitled to your opinion, I personally think > > there are enough requirements elsewhere to have both CC and CV > > functions. But we digress. Are you actually asking that the CC > > functionality be removed from the draft or just making a general > > comment? > > > > > - 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. > > > > What does that comment have to do with the actual draft in > > question? > > > > > - 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. > > > > Again, what does this have to do with the actual draft in > > question? > > > > --tom > > > > > > > > > > > > > > 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 > > >> E> 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