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