RE: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
IMO it is a statement of principle going forward. As such it does not fix or make go away the current situation, but it would be an IETF consensus position on a way forward. And I agree with that position. Lots of folks do proprietary deployments, squat on code points etc. That cannot be fixed either, but I do not believe in rewarding it. Dave -Original Message- From: Rolf Winter [mailto:rolf.win...@neclab.eu] Sent: Friday, October 07, 2011 6:39 AM To: David Allan I; ietf@ietf.org; m...@ietf.org Subject: RE: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Dave, could you be more precise about what you think the utility of this document is in this particular situation. I mean, what will its effect be in the current situation. What will change after this document has been published. It seems everybody believes the situation will be resolved once this document receives its RFC number. I cannot see that. Could you give me more detail? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of David Allan I Sent: Donnerstag, 6. Oktober 2011 01:05 To: ietf@ietf.org; m...@ietf.org Subject: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam- considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC I think it is unfortunate that we are in a situation where such a document has utility. But ultimately it does. Therefore I support the publication of draft-sprecher... D MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the two solutions problem with special reference to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG. Thanks, Adrian ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
I think it is unfortunate that we are in a situation where such a document has utility. But ultimately it does. Therefore I support the publication of draft-sprecher... D MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the two solutions problem with special reference to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG. Thanks, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 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 Stan
HI Erminio: The comments that were raised during the day long discussion with the editors at the SG15 plenary resulted in those comments appearing in the liasion IMO in an actionable form and resulted in a constructive outcome. I enjoyed that level of cooperation. The comments that were punted over the wall with no discussion (depsite requests to allocate meeting time to do so) in some cases were sufficiently vague as to have no constructive value or not have a recognizable issue to be addressed. A request to have the commenters identified in the liaison so that comments that were unclear could be followed up upon by the editors was refused. Apparently that is not done and I would go so far as to suggest that blanket of anonymity diminished the quality of the liaison. The result of this process was that the only recourse to go what does this mean? was a complete liaison cycle. For some comments, stomaching a multi-month delay to clarify what the actual issue was that resulted in a comment like describe the start-up procedure was not reasonable, especially given SG15s continual complaint on how slow the IETF was. Such comments had to be weighed against the nature of comments from the larger reviewing community that seemed to have no issue with the completeness of the document content and perhaps had actually read it and the supporting documents. I'll call out an example: a comment that appeared more than once in the liaison was clarify the raising/clearing of defects as well as any consequent actions which I can only interpret as section 3.7 of the document not having been read. E.g. the TOC is: 3.7.1. Session initiation and Modification 13 3.7.2. Defect entry criteria13 3.7.3. Defect entry consequent action 14 3.7.4. Defect exit criteria 15 3.7.5. State machines 15 ...and if there was a deficiency in the descriptions it was not identified, and we're not mind readers. So that is both the history and why some comments were rejected. If you can suggest a constructive way to proceed that is not simply a waste of everyone's time, I'll listen.. Cheers Dave -Original Message- From: erminio.ottone...@libero.it [mailto:erminio.ottone...@libero.it] Sent: Wednesday, July 13, 2011 1:28 PM To: David Allan I; l...@pi.nu; Rui Costa Cc: m...@ietf.org; ietf@ietf.org; IETF-Announce Subject: R: 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 Do you mean that ITU-T comments were discussed and resolution agreed during the ITU-T meeting? If this is the case, why the LS just provides the comments and not the agreed resolution? Why some ITU-T comments have been then rejected? Messaggio originale Da: david.i.al...@ericsson.com Data: 6-lug-2011 19.35 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, l...@pi.nu l...@pi.nu, Rui Costarco...@ptinovacao.pt Cc: m...@ietf.orgm...@ietf.org, ietf@ietf.orgietf@ietf.org, IETF- Announceietf-annou...@ietf.org Ogg: RE: [mpls] R: Re: Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLSTransport 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
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. Well IMO there was not a lot of interest in T-MPLS until the IETF was going to re-define it and make it compatible with IP/MPLS. So there was an industry wide design intent implied here. IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which. That is because MPLS-TP is not a new techology, it is an addition to the entire MPLS protocol suite. Hope this helps D -Original Message- From: David Allan I [mailto:david.i.al...@ericsson.com] Sent: quarta-feira, 6 de Julho de 2011 19:25 To: erminio.ottone...@libero.it; Rui Costa; ietf@ietf.org; IETF-Announce Cc: m...@ietf.org 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.al...@ericsson.com] Sent: quarta-feira, 6 de Julho de 2011 18:36 To: erminio.ottone...@libero.it; l...@pi.nu; Rui Costa Cc: m...@ietf.org; ietf@ietf.org; 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...@libero.it [mailto:erminio.ottone...@libero.it] Sent: quarta-feira, 6 de Julho de 2011 18:34 To: Rui Costa; ietf@ietf.org; IETF-Announce Cc: m...@ietf.org 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...@libero.it [mailto:erminio.ottone...@libero.it] Sent: quarta-feira, 6 de Julho de 2011 18:26 To: l...@pi.nu; Rui Costa Cc: m...@ietf.org; ietf@ietf.org; 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
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:tnad...@lucidvision.com] Sent: Friday, July 08, 2011 8:27 AM To: neil.2.harri...@bt.com Cc: rco...@ptinovacao.pt; David Allan I; stbry...@cisco.com; m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org 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.harri...@bt.com 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 reliablewe 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 messagevery 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 modewho 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: 180 -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Rui Costa Sent: 08 July 2011 01:15 To: David Allan I; Stewart Bryant Cc: ietf@ietf.org; IETF-Announce; m...@ietf.org 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
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.harri...@bt.com [mailto:neil.2.harri...@bt.com] Sent: Friday, July 08, 2011 9:40 AM To: David Allan I; tnad...@lucidvision.com Cc: rco...@ptinovacao.pt; stbry...@cisco.com; m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org 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.al...@ericsson.com] Sent: 08 July 2011 17:30 To: Thomas Nadeau; Harrison,N,Neil,DKQ7 R Cc: rco...@ptinovacao.pt; stbry...@cisco.com; m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org 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:tnad...@lucidvision.com] Sent: Friday, July 08, 2011 8:27 AM To: neil.2.harri...@bt.com Cc: rco...@ptinovacao.pt; David Allan I; stbry...@cisco.com; m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org 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.harri...@bt.com 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 reliablewe 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 messagevery 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 modewho 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
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: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of erminio.ottone...@libero.it Sent: Wednesday, July 06, 2011 10:26 AM To: l...@pi.nu; Rui Costa Cc: m...@ietf.org; ietf@ietf.org; IETF-Announce Subject: [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 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? Messaggio originale Da: l...@pi.nu Data: 6-lug-2011 17.44 A: Rui Costarco...@ptinovacao.pt Cc: m...@ietf.orgm...@ietf.org, ietf@ietf.orgietf@ietf.org, IETF- Announceietf-annou...@ietf.org Ogg: Re: [mpls] Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (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 On 2011-07-05 00:02, Rui Costa wrote: 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-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The IESG Sent: quinta-feira, 30 de Junho de 2011 14:47 To: IETF-Announce Cc: m...@ietf.org 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
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 Messaggio originale Da: rco...@ptinovacao.pt Data: 5-lug-2011 0.02 A: ietf@ietf.orgietf@ietf.org, IETF-Announceietf-annou...@ietf.org Cc: m...@ietf.orgm...@ietf.org Ogg: Re: [mpls] Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive ConnectivityVerification, Continuity Check and Remote Defect indication for MPLSTransport 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-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The IESG Sent: quinta-feira, 30 de Junho de 2011 14:47 To: IETF-Announce Cc: m...@ietf.org 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@ietf.org mailing lists by 2011-07-14. Exceptionally, comments may be sent to i...@ietf.org 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 m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Rui Costa Sent: Monday, July 04, 2011 3:03 PM To: ietf@ietf.org; IETF-Announce Cc: m...@ietf.org 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-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The IESG Sent: quinta-feira, 30 de Junho de 2011 14:47 To: IETF-Announce Cc: m...@ietf.org 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@ietf.org mailing lists by 2011-07-14. Exceptionally, comments may be sent to i...@ietf.org 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 m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
