MalcolmBETTS90013533 is out of the office.
I will be out of the office starting 10/05/2013 and will not return until 20/05/2013. I will not have access to email, I will respond to your message when I return on May 20th.
MalcolmBETTS90013533 is out of the office.
I will be out of the office starting 03/10/2012 and will not return until 22/10/2012. I will not have access to email, I will respond to your message when I return on October 22nd.
MalcolmBETTS90013533 is out of the office.
I will be out of the office starting 25/05/2012 and will not return until 04/06/2012. I will not have access to email, I will respond to your message when I return.
Re: [PWE3] FW: LastCall: draft-betts-itu-oam-ach-code-point-03.txt(Allocationof an Associated Channel Code Point for Use byITU-T Ethernet basedOAM) to Informational RFC
Tom, I have no objections to using the RFC 2119 key words, I am not sure if that is appropriate in an informational track document, I expect that our AD will provide some guidance. Regards, Malcolm t.petch daedu...@btconnect.com 23/03/2012 05:50 AM To Loa Andersson l...@pi.nu, malcolm.be...@zte.com.cn cc ietf@ietf.org Subject Re: [PWE3] FW: LastCall: draft-betts-itu-oam-ach-code-point-03.txt(Allocationofan Associated Channel Code Point for Use byITU-T Ethernet basedOAM) to Informational RFC Loa The one point that jumps out at me is the proposed text Other message types should not be carried behind this code point. or should that be Other message types SHOULD NOT be carried behind this code point. which, in IETF-Land, is a bit different. I prefer the latter. Tom Petch - Original Message - From: Loa Andersson l...@pi.nu To: malcolm.be...@zte.com.cn Cc: ietf@ietf.org Sent: Friday, March 23, 2012 10:44 AM Subject: Re: [PWE3] FW: LastCall: draft-betts-itu-oam-ach-code-point-03.txt(Allocationof an Associated Channel Code Point for Use byITU-T Ethernet basedOAM) to Informational RFC Malcolm, good that we are making some progress! On the experimental code point -- I doesn't seem appropriate to call out the fact that some commercial products has been using an experimental code point in production setting! On the remain (key) disagreements - I will let other people comment for now. /Loa On 2012-03-21 21:33, malcolm.be...@zte.com.cn wrote: Loa, Thank you for your comments and suggestions, please see in line below. Regards, Malcolm ietf-boun...@ietf.org wrote on 12/03/2012 04:31:43 AM: Loa Andersson l...@pi.nu Sent by: ietf-boun...@ietf.org 12/03/2012 04:31 AM To ietf@ietf.org cc Subject Re: [PWE3] FW: Last Call: draft-betts-itu-oam-ach-code- point-03.txt(Allocation of an Associated Channel Code Point for Use byITU-T Ethernet based OAM) to Informational RFC All, I've been asked to clarify thee comments in this mail, I done so by proposing new text to draft-betts-. I hope this helps. Title = Comment: We want to assign a Associated Channel Type. The registry that it will be assigned from is Pseudowire Associated Channel Types; however RFC 5586, makes the Channel Types generic and I think the title should be changed as follows: OLD: Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM NEW: Allocation of an Generic Associated Channel Type for ITU-T MPLS-TP OAM Note: Neither MPLS-TP or OAM are in the RFC Editors list of wellknown acronyms, therfore the title probably should be: NEW: Allocation of an Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance and Administration. MB: No objection to this change Introduction - first paragraph == In the first paragraph of the introduction, there seems to be an oddity in the description of the role of the ietf-tp-oam-analysis document. Instead of: OLD tools defined by the IETF [I-D.ietf-mpls-tp-oam-analysis], that are intended to meet the OAM functional requirements defined in [RFC5860]. NEW: tools described by the IETF [I-D.ietf-mpls-tp-oam-analysis], which are used to meet the OAM functional requirements defined in [RFC5860]. MB: No objection to this change Intrduction - second paragraph == The next paragraph in describing G.8113.1, stumbles over the current vs anticipated future state of G.8113.1 and its relationship to its antecedents. I'm a bit un-certain about the correct terminology, but I think the following change would improve the document. OLD: The ITU-T has documented, in draft new Recommendation [G.8113.1], the use of Ethernet based OAM mechanisms, originally defined in [Y.1731], carried in the MPLS Generic Associated Channel (G-ACh). This approach requires the allocation of an ACH Type from the registry of ACH types maintained by IANA in order that the messages that will be described in [G.8113.1] can be identified by an implementation. NEW: The ITU-T has Draft Recommendation [G.8113.1] documented MPLS OAM which as of this writing is undergoing the ITU-T Traditional Approval Process (TAP). This Recommendation builds upon Ethernet OAM as documented in [Y.1731]. The messages in [G.8113.1] are defined to be carried in a new Associated Channel Type in the MPLS Generaic Associated Channel (G-Ach). In order to carry these messages in an interoperable fashion, an Associated Channel Type from the IANA maintained
Re: [PWE3] FW: Last Call: draft-betts-itu-oam-ach-code-point-03.txt(Allocation of an Associated Channel Code Point for Use byITU-T Ethernet based OAM) to Informational RFC
Loa, Thank you for your comments and suggestions, please see in line below. Regards, Malcolm ietf-boun...@ietf.org wrote on 12/03/2012 04:31:43 AM: Loa Andersson l...@pi.nu Sent by: ietf-boun...@ietf.org 12/03/2012 04:31 AM To ietf@ietf.org cc Subject Re: [PWE3] FW: Last Call: draft-betts-itu-oam-ach-code- point-03.txt(Allocation of an Associated Channel Code Point for Use byITU-T Ethernet based OAM) to Informational RFC All, I've been asked to clarify thee comments in this mail, I done so by proposing new text to draft-betts-. I hope this helps. Title = Comment: We want to assign a Associated Channel Type. The registry that it will be assigned from is Pseudowire Associated Channel Types; however RFC 5586, makes the Channel Types generic and I think the title should be changed as follows: OLD: Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM NEW: Allocation of an Generic Associated Channel Type for ITU-T MPLS-TP OAM Note: Neither MPLS-TP or OAM are in the RFC Editors list of wellknown acronyms, therfore the title probably should be: NEW: Allocation of an Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance and Administration. MB: No objection to this change Introduction - first paragraph == In the first paragraph of the introduction, there seems to be an oddity in the description of the role of the ietf-tp-oam-analysis document. Instead of: OLD tools defined by the IETF [I-D.ietf-mpls-tp-oam-analysis], that are intended to meet the OAM functional requirements defined in [RFC5860]. NEW: tools described by the IETF [I-D.ietf-mpls-tp-oam-analysis], which are used to meet the OAM functional requirements defined in [RFC5860]. MB: No objection to this change Intrduction - second paragraph == The next paragraph in describing G.8113.1, stumbles over the current vs anticipated future state of G.8113.1 and its relationship to its antecedents. I'm a bit un-certain about the correct terminology, but I think the following change would improve the document. OLD: The ITU-T has documented, in draft new Recommendation [G.8113.1], the use of Ethernet based OAM mechanisms, originally defined in [Y.1731], carried in the MPLS Generic Associated Channel (G-ACh). This approach requires the allocation of an ACH Type from the registry of ACH types maintained by IANA in order that the messages that will be described in [G.8113.1] can be identified by an implementation. NEW: The ITU-T has Draft Recommendation [G.8113.1] documented MPLS OAM which as of this writing is undergoing the ITU-T Traditional Approval Process (TAP). This Recommendation builds upon Ethernet OAM as documented in [Y.1731]. The messages in [G.8113.1] are defined to be carried in a new Associated Channel Type in the MPLS Generaic Associated Channel (G-Ach). In order to carry these messages in an interoperable fashion, an Associated Channel Type from the IANA maintained registry Pseudowire Associated Channel Types is to be used. MB: Since the draft will not be published as an RFC until after G.8113.1 is approved we can directly reference the approved Recommendation and I suggest that we modify paragraph to: ITU-T Recommendation [G.8113.1] documents MPLS OAM. This Recommendation builds upon Ethernet OAM as documented in [Y.1731]. The messages in [G.8113.1] are defined to be carried in a new Associated Channel Type in the MPLS Generaic Associated Channel (G-Ach). In order to carry these messages in an interoperable fashion, an Associated Channel Type from the IANA maintained registry Pseudowire Associated Channel Types is to be used. Note there are confusion around some of the Associated Channel acronyms that are refledted in this document. ACh is Associated Channel ACH is Associated Chamnnel Header G-ACh is Generic Associated Channel ACH Type is not used anywhere in IETF documents; we talk about Associated Channel Type or Generic Associated Channel Type (G-ACh Type). MB: Thank you, I will fix this. Introduction - third paragraph == In the third paragraph, there seems to be an unnecessary reference to experimental types. When asking for a code point for a standard, it is not helped to bring up experimental code space. Can we remove the text reading: OLD: without continuing to resorting to the use of an experimental ACH Type, NEW - MB: I do not agree with the deletion of this text, these existing deployments, and the desire to migrate to an allocated code point, are part of the rational for requesting the code point. Section 2 - first paragraph === In section 2, the first sentence refers to Ethernet based OAM messages. As far as I know, the messages in G.8113.1 are either MPLS-TP OAM
Re: הנדון: RE: Last Call:draft-betts-itu-oam-ach-code-point-03.txt(Allocationof an Associated Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational RFC
All, Two points to consider: 1) Below it is stated: In the future, all codepoint allocations to the ITU-T should be tied to one specific, dated revision of their specification only. This is similar to the ITU-T's own processes, such as section 2.2.1 of Rec. A.5, which requires a version number and/or date for referenced outside documents in ITU-T recommendations. However, this is not the complete picture of the ITU process. Section 2.2 of Recommendation A.5 defines the information that must be provided when the inclusion of a normative reference is under consideration. The Authors guide requires that the following text is inserted into the References section of all ITU-T Recommendations: The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. Thus in the ITU the latest version of a referenced document is always considered. 2) Section 2 of draft-betts “Scope of the Ethernet based OAM ACH Type” restricts the use of the code point to the OAM messages necessary to meet the functional requirements of RFC 5860: “The code point allocated by this document is intended to be used only for Ethernet based OAM messages, defined in the ITU-T Recommendation [G.8113.1], carried in the G-ACh . These Ethernet based OAM messages and procedures, address the OAM functional requirements defined in [RFC5860]. Other message types should not be carried behind this code point.” Further only interfaces that support G.8113.1 OAM will act on these OAM messages, any interface that does not support this G-ACh type will discard these OAM messages as defined in RFC5586. Also as stated in the last paragraph of section 2: “All ITU-T Recommendations are subject to revisions. Therefore, the code point allocated by this document may be used for future versions of [G.8113.1].” The intention of this statement is to bring to the attention of the IETF the normal practice in the ITU of developing amendments to Recommendations to fully meet the functional requirements (e.g. adding pro-active loss measurement). Normally any reference to ITU-T Rec G.8113.1 will automatically be directed to the current version (including any amendments). Russ stated in https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=933k2=62185tid=1331648664 : “Some people are using the lack of a code point as the reason that the cannot support the ITU-T document. My approach tells the ITU-T that a code point is available to them IFF they are able to reach consensus. The removes IETF from the discussion. This creates a situation where G.8113.1 succeeded or fails based on the ITU-T members actions, with no finger pointing at the IETF. This is completely a Layer 9 consideration, and it has noting to do with the technical content of the document.” Restricting the application of the code point to a specific version of Recommendation G.8113.1 would require the ITU to deviate from its normal process for enhancing Recommendations and would put the IETF back into the discussion for approval. Regards, Malcolm Sprecher, Nurit (NSN - IL/Hod HaSharon) nurit.sprec...@nsn.com Sent by: ietf-boun...@ietf.org 13/03/2012 03:09 PM To Andrew G. Malis agma...@gmail.com, ext Ross Callon rcal...@juniper.net cc ietf@ietf.org Subject הנדון: RE: Last Call:draft-betts-itu-oam-ach-code-point-03.txt(Allocationof an Associated Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational RFC Ross, i am afraid that you missed the point. There will not be a final version since as written in draft-betts, all ITU recommendations are subject to revisions, and the code point will also be used for future revisions of the document. New messages/protocols can be defined in future revisions of the recommendation and they will use the same code point that is allocated for the first version. This is a real issue. Regards, Nurit -הודעה מקורית- מאת: ext Ross Callon נשלח: 13/03/2012, 19:27 אל: Andrew G. Malis; Sprecher, Nurit (NSN - IL/Hod HaSharon) עותק: ietf@ietf.org נושא: RE: Last Call:draft-betts-itu-oam-ach-code-point-03.txt(Allocationof an Associated Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational RFC I agree that the allocation of a code point should be to a specific version of 8113.1, and specifically should be to the final version that is approved by the ITU-T (assuming that a final version of 8113.1 will be approved by the ITU-T). This would imply that draft-betts-itu-oam-ach-code-point should contain a normative reference to the final approved version of 8113.1. Given normal
RE: הנדון: RE: Last Call:draft-betts-itu-oam-ach-code-point-03.txt(Allocationof an Associated Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational RFC
Nurit, Section 2 “Scope of the Ethernet based OAM ACH Type” contains the following text: The code point allocated by this document is intended to be used only for Ethernet based OAM messages, defined in the ITU-T Recommendation [G.8113.1], carried in the G-ACh . These Ethernet based OAM messages and procedures, address the OAM functional requirements defined in [RFC5860]. Other message types should not be carried behind this code point. The restrictions on the future use of the code point could be made more explicit by modifying the text as follows: The code point allocated by this document should only be used for Ethernet based OAM messages, defined in the ITU-T Recommendation [G.8113.1], carried in the G-ACh. The messages and procedures carried behind this code point, are restricted to only those that the address the OAM functional requirements defined in [RFC5860]. Other message types should not be carried behind this code point. I hope that this addresses your concern. Regards, Malcolm Sprecher, Nurit (NSN - IL/Hod HaSharon) nurit.sprec...@nsn.com 14/03/2012 06:43 AM To Sprecher, Nurit (NSN - IL/Hod HaSharon) nurit.sprec...@nsn.com, Andrew G. Malis agma...@gmail.com, ext Ross Callon rcal...@juniper.net, malcolm.be...@zte.com.cn cc ietf@ietf.org Subject RE: הנדון: RE: Last Call:draft-betts-itu-oam-ach-code-point-03.txt(Allocationof an Associated Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational RFC Malcolm, As mentioned before, I cannot support the publication of the current version of draft-betts...it must be revised first to address the concerns I and others raised on the list. Maybe you could clarify how the text in your draft can be improved to protect the use of the code point from future extensions beyond the purpose of the code point allocation? Best regards, Nurit -snip ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Questions about draft-betts-itu-oam-ach-code-point
Hi Adrian, Please see in line below for my response to your questions. I will post a revised version of the draft tomorrow. Regards, Malcolm Adrian Farrel adr...@olddog.co.uk Sent by: ietf-boun...@ietf.org 09/12/2011 05:49 AM Please respond to adr...@olddog.co.uk To draft-betts-itu-oam-ach-code-po...@tools.ietf.org, 'Huub helvoort' huub.van.helvo...@huawei.com cc m...@ietf.org, ietf@ietf.org Subject Questions about draft-betts-itu-oam-ach-code-point Hi Malcolm and Huub, I have squeezed a little time from the current ITU-T meeting to look at your draft and write-up. I have also read the email threads on the IETF discussion list and the MPLS list. Sorry that this has taken me a week to process, but your publication request came at pretty much the worst possible time for getting me to do this task. I don't like proliferating threads across multiple mailing lists. On the other hand it is difficult to ensure that all the constituencies are present, so I am perpetuating the cross-posting. My review of the document... 1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. I think only one of these is real (the spurious space in a citation). The other nits are spurious caused by citations wrapping across lines. Could you please keep a note of the nit so that you can fix it the next time the draft is respun or so it can be captured in an RFC Editor Note at a later stage (you don't have to post a new revision to address this now unless you really want to). [MB] OK fixed in the update 2. This document requests a code point from a registry that contains code points that are used equally for MPLS LSPs and pseudowires. I can't tell from the I-D whether it is your intention that your code point would also be applicable in both cases. What is your intention? Is this obvious from G.8113.1 or does it need to be clarified? [MB] The draft requests a code point to support Ethernet based OAM messages the use of these messages on MPLS-TP LSPs and PWs is described in G.8113.1 other uses are not prohibited by this draft. My review of the write-up and discussions... 3. There seems to be quite a feeling on the mailing lists that this document should be run through the MPLS working group. The write-up makes a case for progressing it as AD sponsored. As far as I can see, the main assertions to answer are as follows. Do you have a view on these points before I make a decision on what to do? a. This is a proposal to use an MPLS code point and so is part of MPLS by definition. b. The type of network being managed by the OAM described in G.8113.1 is an MPLS network. Therefore, this is clearly relevant to the MPLS working . Do you object to this going through the MPLS on principle, or were you just hoping to save the WG the work? If the latter, and if the WG wants to look at the draft, the easiest approach seems to be to redirect the work to the working group. [MB] G.8113.1 supports a subset of the functions defined in draft-bhh-mpls-tp-oam-y1731-08. The -00 version was posted in March 2009, the draft was presented at several meetings in 2009 and early 2010 and had extensive discussion on the MPLS mailing list. However, the MPLS WG have, by rough consensus, adopted a different approach. Therefore, further review by the MPLS WG is of little value. 4. G.8113.1 is clearly important to understanding to which the code point is being put. Thus, an available and stable copy of group. G.8113.1 will be key to the last call review of you I-D. Can you make a stable copy available (for example, through liaison)? How does the editing work currently in progress in the SG15 meeting affect that availability? [MB] The draft is requesting a code point for the version of G.8113.1 that was forwarded to WTSA by SG 15 in December, this is the same as the draft that was determined in February 2011, I am not anticipating any changes prior to the approval decision at WTSA. None of the changes in G.8113.1 that were discussed during the drafting sessions and were anticipated in draft-betts-itu-oam-ach-code-point-01 were implemented, as I stated above I will post a new version draft-betts-itu-oam-ach-code-point to correctly reflect the content and title of G.8113.1 later this week. 5. Can you clarify for me why the suggested value has been suggested. This will help guide IANA who would normally do their allocation in a tidy way. [MB] This value corresponds to the Ethertype used for Ethernet OAM Looking forward to your reply. Thanks, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Questions about draft-betts-itu-oam-ach-code-point
Hi Adrian, I can confirm that the draft is requesting a code point for the version of G.8113.1 that was forwarded to WTSA by SG 15, this is the same as the draft that was determined in February 2011, I am not anticipating any changes prior to the approval decision at WTSA. None of the changes in G.8113.1 that were anticipated in draft-betts-itu-oam-ach-code-point-01 were implemented, I will post a new version draft-betts-itu-oam-ach-code-point to correctly reflect the content and title on G.8113.1 and respond to the other questions later this week. Regards, Malcolm Adrian Farrel adr...@olddog.co.uk 09/01/2012 12:33 PM Please respond to adr...@olddog.co.uk To draft-betts-itu-oam-ach-code-po...@tools.ietf.org, 'Huub helvoort' huub.van.helvo...@huawei.com cc m...@ietf.org, ietf@ietf.org Subject RE: Questions about draft-betts-itu-oam-ach-code-point Hi Huub and Malcolm, I recognise that the intervening month between my original email and this one included an SG15 meeting, Christmas, and New Year, but I had hoped for a response by now so that we could work out what to do with the document. In the meantime, at least my question 4 has progressed. Can you confirm that the version of G.8113.1 for which a code point is requested is that which has been sent to WTSA by SG15 (i.e., that which was determined), and that there are no plans to make any updates or revisions to that document until after it has been approved. Thanks, Adrian -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: 09 December 2011 10:49 To: draft-betts-itu-oam-ach-code-po...@tools.ietf.org; 'Huub helvoort' Cc: m...@ietf.org; ietf@ietf.org Subject: Questions about draft-betts-itu-oam-ach-code-point Hi Malcolm and Huub, I have squeezed a little time from the current ITU-T meeting to look at your draft and write-up. I have also read the email threads on the IETF discussion list and the MPLS list. Sorry that this has taken me a week to process, but your publication request came at pretty much the worst possible time for getting me to do this task. I don't like proliferating threads across multiple mailing lists. On the other hand it is difficult to ensure that all the constituencies are present, so I am perpetuating the cross-posting. My review of the document... 1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. I think only one of these is real (the spurious space in a citation). The other nits are spurious caused by citations wrapping across lines. Could you please keep a note of the nit so that you can fix it the next time the draft is respun or so it can be captured in an RFC Editor Note at a later stage (you don't have to post a new revision to address this now unless you really want to). 2. This document requests a code point from a registry that contains code points that are used equally for MPLS LSPs and pseudowires. I can't tell from the I-D whether it is your intention that your code point would also be applicable in both cases. What is your intention? Is this obvious from G.8113.1 or does it need to be clarified? My review of the write-up and discussions... 3. There seems to be quite a feeling on the mailing lists that this document should be run through the MPLS working group. The write-up makes a case for progressing it as AD sponsored. As far as I can see, the main assertions to answer are as follows. Do you have a view on these points before I make a decision on what to do? a. This is a proposal to use an MPLS code point and so is part of MPLS by definition. b. The type of network being managed by the OAM described in G.8113.1 is an MPLS network. Therefore, this is clearly relevant to the MPLS working . Do you object to this going through the MPLS on principle, or were you just hoping to save the WG the work? If the latter, and if the WG wants to look at the draft, the easiest approach seems to be to redirect the work to the working group. 4. G.8113.1 is clearly important to understanding to which the code point is being put. Thus, an available and stable copy of group. G.8113.1 will be key to the last call review of you I-D. Can you make a stable copy available (for example, through liaison)? How does the editing work currently in progress in the SG15 meeting affect that availability? 5. Can you clarify for me why the suggested value has been suggested. This will help guide IANA who would normally do their allocation in a tidy way. Looking forward to your reply. Thanks, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Questions about draft-betts-itu-oam-ach-code-point
Hi Adrian, Thank you for finding time to respond to this request. As you know I was attending the same 2 week SG 15 meeting and was probably at least as busy as you given my official role in the meeting. I will update draft-betts-itu-oam-ach-code-point early in the new year based on the results of SG 15 the ended last Friday and your comments. I will also discussan update of the shepherd write up with Huub. Regards, Malcolm Adrian Farrel adr...@olddog.co.uk Sent by: ietf-boun...@ietf.org 09/12/2011 05:49 AM Please respond to adr...@olddog.co.uk To draft-betts-itu-oam-ach-code-po...@tools.ietf.org, 'Huub helvoort' huub.van.helvo...@huawei.com cc m...@ietf.org, ietf@ietf.org Subject Questions about draft-betts-itu-oam-ach-code-point Hi Malcolm and Huub, I have squeezed a little time from the current ITU-T meeting to look at your draft and write-up. I have also read the email threads on the IETF discussion list and the MPLS list. Sorry that this has taken me a week to process, but your publication request came at pretty much the worst possible time for getting me to do this task. I don't like proliferating threads across multiple mailing lists. On the other hand it is difficult to ensure that all the constituencies are present, so I am perpetuating the cross-posting. My review of the document... 1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. I think only one of these is real (the spurious space in a citation). The other nits are spurious caused by citations wrapping across lines. Could you please keep a note of the nit so that you can fix it the next time the draft is respun or so it can be captured in an RFC Editor Note at a later stage (you don't have to post a new revision to address this now unless you really want to). 2. This document requests a code point from a registry that contains code points that are used equally for MPLS LSPs and pseudowires. I can't tell from the I-D whether it is your intention that your code point would also be applicable in both cases. What is your intention? Is this obvious from G.8113.1 or does it need to be clarified? My review of the write-up and discussions... 3. There seems to be quite a feeling on the mailing lists that this document should be run through the MPLS working group. The write-up makes a case for progressing it as AD sponsored. As far as I can see, the main assertions to answer are as follows. Do you have a view on these points before I make a decision on what to do? a. This is a proposal to use an MPLS code point and so is part of MPLS by definition. b. The type of network being managed by the OAM described in G.8113.1 is an MPLS network. Therefore, this is clearly relevant to the MPLS working . Do you object to this going through the MPLS on principle, or were you just hoping to save the WG the work? If the latter, and if the WG wants to look at the draft, the easiest approach seems to be to redirect the work to the working group. 4. G.8113.1 is clearly important to understanding to which the code point is being put. Thus, an available and stable copy of group. G.8113.1 will be key to the last call review of you I-D. Can you make a stable copy available (for example, through liaison)? How does the editing work currently in progress in the SG15 meeting affect that availability? 5. Can you clarify for me why the suggested value has been suggested. This will help guide IANA who would normally do their allocation in a tidy way. Looking forward to your reply. Thanks, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Loa, As per my previous email , I have only seen one response to the 12 points that I raised, I do not agree with your assessment of this document. Just to remind you of the points made by myself and several others on SONET and SDH: SONET is a true subset of SDH: The SDH standard supports both the North American and Japanese 24 channel/T1/T3 hierarchy and the European 30 channel/E1/E4 based hierarchy within a single multiplexing structure. SDH has no options for payloads at VC-4 (150Mb/s) and above. This has provided the basis for common solutions for packet based clients (GFP). SDH allows T1/T3 services to be delivered in Europe and E1 services to be delivered in North America using a common infra structure. A single standard that supported either the T1/T3 hierarchy or the E1 hierarchy would not have been successful. Deployment of a E1 only standard in North America would have required the conversion of all of the 24 channel/T1 deployed equipment and services into the 30 channel/E1 format. Similarly deployment of a T1 only standard in Europe would have required the conversion of all of the 30 channel/E1 equipment and services into 24 channel/T1 format. Clearly given the existing network deployments (in 1988) this was not a practical proposition. Regards, Malcolm Loa Andersson l...@pi.nu Sent by: ietf-boun...@ietf.org 23/10/2011 02:07 PM To ietf@ietf.org cc The IESG iesg-secret...@ietf.org, IETF-Announce ietf-annou...@ietf.org Subject Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC All, I've taken time to re-read this draft over the weekend. I still think it is well-written and extremely to the point; it is in the interest of the IETF to publish. I support publication of the draft. Admittedly there are some issues around the e.g. the description of the SDH/SONNET and the standardization of those technologies. Having been involved in development of equipment that could run both SDH and SONET, my understanding is that both when it comes to chips and SW the split, even after the compromise, lead to higher costs and longer schedules. we would have been in a better shape with one standard also that time. Maybe the authors should reflect the facts that Huub correctly point out in his early mail on this thread, where he describes a situation that was much worse than what is in the document. /Loa On 2011-09-26 12:42, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM' draft-sprecher-mpls-tp-oam-considerations-01.txt as an Informational RFC 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-10-24. 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 The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology for use in transport network deployments. That is, MPLS-TP is a set of functions and features selected from the wider MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks. During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment. One major set of additions provides enhanced support for Operations, Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address these OAM requirements, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization. The file can be obtained via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Loa, As per my previous email , I have only seen one response to the 12 points that I raised, I do not agree with your assessment of this document. Just to remind you of the points made by myself and several others on SONET and SDH: SONET is a true subset of SDH: The SDH standard supports both the North American and Japanese 24 channel/T1/T3 hierarchy and the European 30 channel/E1/E4 based hierarchy within a single multiplexing structure. SDH has no options for payloads at VC-4 (150Mb/s) and above. This has provided the basis for common solutions for packet based clients (GFP). SDH allows T1/T3 services to be delivered in Europe and E1 services to be delivered in North America using a common infra structure. A single standard that supported either the T1/T3 hierarchy or the E1 hierarchy would not have been successful. Deployment of a E1 only standard in North America would have required the conversion of all of the 24 channel/T1 deployed equipment and services into the 30 channel/E1 format. Similarly deployment of a T1 only standard in Europe would have required the conversion of all of the 30 channel/E1 equipment and services into 24 channel/T1 format. Clearly given the existing network deployments (in 1988) this was not a practical proposition. Regards, Malcolm Loa Andersson l...@pi.nu Sent by: ietf-boun...@ietf.org 23/10/2011 02:07 PM To i...@ietf.org cc The IESG iesg-secret...@ietf.org, IETF-Announce ietf-announce@ietf.org Subject Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC All, I've taken time to re-read this draft over the weekend. I still think it is well-written and extremely to the point; it is in the interest of the IETF to publish. I support publication of the draft. Admittedly there are some issues around the e.g. the description of the SDH/SONNET and the standardization of those technologies. Having been involved in development of equipment that could run both SDH and SONET, my understanding is that both when it comes to chips and SW the split, even after the compromise, lead to higher costs and longer schedules. we would have been in a better shape with one standard also that time. Maybe the authors should reflect the facts that Huub correctly point out in his early mail on this thread, where he describes a situation that was much worse than what is in the document. /Loa On 2011-09-26 12:42, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM' draft-sprecher-mpls-tp-oam-considerations-01.txt as an Informational RFC 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 i...@ietf.org mailing lists by 2011-10-24. 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 The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology for use in transport network deployments. That is, MPLS-TP is a set of functions and features selected from the wider MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks. During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment. One major set of additions provides enhanced support for Operations, Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address these OAM requirements, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization. The file can be obtained via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC - comment 2
Loa, I still do not understand how you can claim that the words from slide 113 of RFC 5317 and quoted in section 1.1 of draft-sprecher-mpls-tp-oam-considerations-01: It is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile The architecture allows for a single OAM technology for LSPs, PWE and a deeply nested network Represent a decision or even a recommendation. However, if as you insist it was a decision can you explain why the IETF chose to ignore this decision and initially defined different encapsulations for the PW and LSP OAM and subsequently defined a second encapsulation for PW OAM. So that now we have two encapsulations for OAM in MPLS-TP PWs. Regards, Malcolm Loa Andersson l...@pi.nu 14/10/2011 10:37 AM To malcolm.be...@zte.com.cn cc Ietf@ietf.org Subject Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC - comment 2 Malocolm, there is no conflict - the one OAM solution was and is a decision. /Loa On 2011-10-14 15:59, malcolm.be...@zte.com.cn wrote: Loa, I have added - comment 2 to the subject line and deleted all the other comments. I cannot find section 1.1 or the text one OAM solution in the PDF version of RFC 5317. The last paragraph of section 1 states: In the case of a conflict between the summary and the slides, the slides take precedence. Since those slides were the basis of an important agreement between the IETF and the ITU-T, it should further be noted that in the event that the PDF version of the slides differs from those emailed to ITU-T and IETF management on 18 April 2008 by the co-chairs of the JWT, the emailed slides take precedence. The full quote from slide 12 is: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the **agreed upon starting point** for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements I must also remind you that the JWT did not have the power to make decision for the ITU or IETF as stated in TD515/PLEN that established the ad group on MPLS-TP and the JWT: The Joint Working Team is the union of the ad hoc and design teams. It has no official affiliation or status with either the ITU-T or the IETF but will provide a forum for open communication and cooperative work This is aligned with normal process in the IETF where a design team cannot make decisions for a Working Group. Therefore, my proposed clarification of the context of the one solution statement should be included in draft-sprecher-mpls-tp-oam-considerations. Regards, Malcolm *Loa Andersson l...@pi.nu* 14/10/2011 02:15 AM To malcolm.be...@zte.com.cn cc Ietf@ietf.org Subject Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC All, juat one small comment on how slide 12 of the JWT report is (mis)used in this debate. The text says: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008. The paragraph is correct and it says that the presentation includes - assumptions - discussion points - decisions The statement on one OAM solution from section 1.1 of RFC5317 clearly falls into the *decision* category. As such it rather support publishing the draft rather than indicating that we shouldn't. /Loa On 2011-10-14 04:31, malcolm.be...@zte.com.cn wrote: Below are my comments on this draft, these are in addition to the comments that I have provided previously. I also support the comments that propose the deletion of sections 4, 5 and 6. I have numbered my comments (1-12) to simplify identification for those who wish to respond. I do not support approval of this draft in its current form. Regards, Malcolm 2) Quote from RFC5317 Section 1.1 includes the following: [RFC5317] includes the analysis that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. The context of this quote from slide 113 should be clarified; slide 12 states of RFC 5317 states: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the *agreed upon starting point* for the technical analysis of the T-MPLS requirements from the ITU-T
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC - comment 2
Loa, I have added - comment 2 to the subject line and deleted all the other comments. I cannot find section 1.1 or the text one OAM solution in the PDF version of RFC 5317. The last paragraph of section 1 states: In the case of a conflict between the summary and the slides, the slides take precedence. Since those slides were the basis of an important agreement between the IETF and the ITU-T, it should further be noted that in the event that the PDF version of the slides differs from those emailed to ITU-T and IETF management on 18 April 2008 by the co-chairs of the JWT, the emailed slides take precedence. The full quote from slide 12 is: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the *agreed upon starting point* for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements I must also remind you that the JWT did not have the power to make decision for the ITU or IETF as stated in TD515/PLEN that established the ad group on MPLS-TP and the JWT: The Joint Working Team is the union of the ad hoc and design teams. It has no official affiliation or status with either the ITU-T or the IETF but will provide a forum for open communication and cooperative work This is aligned with normal process in the IETF where a design team cannot make decisions for a Working Group. Therefore, my proposed clarification of the context of the one solution statement should be included in draft-sprecher-mpls-tp-oam-considerations. Regards, Malcolm Loa Andersson l...@pi.nu 14/10/2011 02:15 AM To malcolm.be...@zte.com.cn cc Ietf@ietf.org Subject Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM)to Informational RFC All, juat one small comment on how slide 12 of the JWT report is (mis)used in this debate. The text says: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008. The paragraph is correct and it says that the presentation includes - assumptions - discussion points - decisions The statement on one OAM solution from section 1.1 of RFC5317 clearly falls into the *decision* category. As such it rather support publishing the draft rather than indicating that we shouldn't. /Loa On 2011-10-14 04:31, malcolm.be...@zte.com.cn wrote: Below are my comments on this draft, these are in addition to the comments that I have provided previously. I also support the comments that propose the deletion of sections 4, 5 and 6. I have numbered my comments (1-12) to simplify identification for those who wish to respond. I do not support approval of this draft in its current form. Regards, Malcolm 2) Quote from RFC5317 Section 1.1 includes the following: [RFC5317] includes the analysis that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. The context of this quote from slide 113 should be clarified; slide 12 states of RFC 5317 states: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the *agreed upon starting point* for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements Proposal: Insert the following text before the quoted text: [RFC 5317] provides a collection of assumptions, discussion points and decisions that the JWT has had during the months of March and April, 2008. This represents the agreed upon starting point for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements. Included in this analysis is the statement that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Below are my comments on this draft, these are in addition to the comments that I have provided previously. I also support the comments that propose the deletion of sections 4, 5 and 6. I have numbered my comments (1-12) to simplify identification for those who wish to respond. I do not support approval of this draft in its current form. Regards, Malcolm 1) Two encapsulations for PW OAM The draft provides the Reasons for Selecting a Single Solution for MPLS-TP OAM. However, two different encapsulations have been defined for OAM messages in the MPLS-TP PW. One uses just the ACh the other uses both the GAL and ACh. These two encapsulations must be identified and rationalized in the context of selecting a single solution. Particular attention should be paid to the text from RFC5317 quoted in section 1.1 “…the architecture allows for a single OAM technology for LSPs, PWs…” 2) Quote from RFC5317 Section 1.1 includes the following: [RFC5317] includes the analysis that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. The context of this quote from slide 113 should be clarified; slide 12 states of RFC 5317 states: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the agreed upon starting point for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements Proposal: Insert the following text before the quoted text: [RFC 5317] provides a collection of assumptions, discussion points and decisions that the JWT has had during the months of March and April, 2008. This represents the agreed upon starting point for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements. Included in this analysis is the statement that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. 3) Section 1.2 The Development of a Parallel MPLS-TP OAM Solution The section should be deleted or rewritten since it includes a number of assertions that have not been substantiated and are not supported by a significant number of participants. 4) Consistent with existing MPLS OAM Section 3.3 states: Given this intention for compatibility, it follows that the MPLS-TP OAM protocols should be consistent with the existing, deployed MPLS OAM This statement requires further clarification and justification since: a) The existing MPLS OAM tools use an IP encapsulation, the MPLS-TP OAM tools use a GAL/ACh encapsulation; and: b) The only existing deployed OAM tools were BFD and LSP Ping, all the other OAM tools are new so it is difficult to understand the concept of compatible. 5) MPLS as a Convergence Technology Section 3.2 includes the statement: “When we arrive at our destination of TCP/IP/MPLS running directly over fiber, the operators will use MPLS OAM tools to make this work.” This statement is technically incorrect; MPLS must be encapsulated in a L2 and L1 protocol before it can be transmitted over a physical media. Further I have seen no evidence that network operator will use MPLS to maintain the optical network infrastructure e.g. amplifiers, WDM couplers etc. The section is based on the assumption that the network will rapidly converge to being just IP/MPLS. This is not a universally accepted view. Section 3.2 should be deleted. 6) Section 3.3 End to end OAM I agree that end to end OAM is important for maintaining a service. However, we also need OAM to maintain the transport infrastructure that is independent of the services (or even the presence of a service). Section 3.3 also states: This is a design paradigm that has guided the IETF in the development of its exiting network layer connectivity OAM protocols. For each network layer protocol there is only one ping, trace route, or fast connectivity protocol, and amongst these there is a common design approach. This is not correct the IETF have defined multiple protocols for PWs. Section 3.3 should be deleted or rewritten 7) Section 3.5 Interworking I agree that interworking adds complexity and should be avoided. However this section includes a large amount of general considerations that are not relevant to MPLS-TP OAM for example: Universal deployment of both OAM protocols … introduces additional testing requirements to ensure there are no conflicts when both protocols are run on a common platform. The use of the ACh to distinguish between protocols avoids the possibility of
Re: ITU-T Beijing meeting [Was: Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC]
Adrian, A similar statement is already included in draft-tsb-mpls-tp-ach-ptn-01 5.3. LSP or PW originating in a PTN network and terminating in a PSN network In this case the PW (or LSP) originates (or terminates) in a PTN and terminates (or originates) in a PSN. The default OAM for the end to end LSP or PW is PSN. This could be restated to avoid use of the terms PSN and PTN as: Any LSP or PW that interconnects between a domain that uses the MPLS tool set defined in [I-D.ietf-mpls-tp-oam-analysis] and a domain that normally uses the Ethernet tools defined in ITU-T Recommendation [G.8113.1] must use the MPLS tool set. I also noted a helpful response from Ross Callon indicating that the IETF has a history of documenting pre-standard tools that are widely deployed. Allocation of a ACH code point to the ITU for use only for Ethernet OAM carried in the MPLS ACH. With a proviso that it must not be used as a mechanism to carry other messages or protocols hiding behind the ACH Type. Therefore, only the messages and procedures that address the OAM requirements defined in [RFC 5860], as defined in the ITU-T Recommendation [G.8113.1], could be carried using this code point. Would it be helpful to respin draft-tsb-mpls-tp-ach-ptn along these lines to recognize the already widespread deployment of MPLS-TP using Ethernet based OAM pdus and constrain/simplify the rules for interconnection? Regards, Malcolm Adrian Farrel adr...@olddog.co.uk 10/10/2011 05:43 AM Please respond to adr...@olddog.co.uk To ma.yu...@zte.com.cn, malcolm.be...@zte.com.cn, huubatw...@gmail.com cc 'IETF Discussion' ietf@ietf.org Subject ITU-T Beijing meeting [Was: Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC] Yuxia wrote: I also agree with Huub. As a consensus reached in Beijing meeting, mechanism using the tools defined for MPLS is a default tool set and another using the tools defined in G.8013/Y.1731 is an optional one. That is a an interesting and helpful statement. Obviously, most IETF participants were not present at this meeting: is there a possibility that this message could be communicated to the IETF in a more official way? Thanks, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Huub, I agree. Regards, Malcolm Huub van Helvoort huubatw...@gmail.com Sent by: ietf-boun...@ietf.org 09/10/2011 07:42 AM Please respond to huubatw...@gmail.com To IETF Discussion ietf@ietf.org cc Subject Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC All, I still do not support this draft. Section 6 focusses on the interworking between two toolsets In transport networks we *never* have peer-2-peer OAM interworking. If it was required it would have explicitly been mentioned in the MPLS-TP requirements RFC. Why don't you simply read draft-tsb-mpls-tp-ach-ptn or Annex B of G.8110.1 where it is documented how different toolsets can be deployed in a network without any issues. Section 6 is totally irrelevant. Regards, Huub. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Russ, You may not be fully aware of the context of the statement in RFC 5317: As the co-chair of the JTW and co-editor of the JWT report I must point out the context of the text that you have quoted: First, the text is on slide 113, slide 12 states: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the agreed upon starting point for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements Second: The discussion point that drove the text on slide 113 was the consideration that PWs and LSPs may have different OAM. The reality is that the solution standardized uses different encapsulations for the PW (no GAL) and LSP (uses the GAL). Regards, Malcolm Russ Housley hous...@vigilsec.com Sent by: ietf-boun...@ietf.org 08/10/2011 11:02 AM To IETF ietf@ietf.org cc Subject Re: 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 support publication of this draft, although the SONET discussion could be discarded. Also, I would like to see a reference to RFC 5921 in the introduction. RFC 5317 calls for one, and only one, protocol solution. At least that is how I read JWT Agreement. The most relevant text seems to be in Section 9: They stated that in their view, it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. Since the publication of RFC 5317, the MPLS WG consensus continues to be that only one OAM solution should become a standard. Russ On Oct 5, 2011, at 11:02 PM, Rui Costa wrote: c) To the question which requirement stated in the RFCs are not satisfied by the singe OAM solution defined in IETF?: For instance, RFC5860 2.2.3: The protocol solution(s) developed to perform this function proactively MUST also apply to [...] point-to-point unidirectional LSPs, and point-to- multipoint LSPs. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Brian, The second solution already exists, (300,00+ nodes already deployed - see other emails on this thread). We must acknowledge this and find the most cost effective way of allowing interconnection. That is best achieved by recognizing the Ethernet tool set based solution and defining interconnection such that an interworking function is not required. This has already been proposed and documented in draft revised Recommendation G.8110.1 (now in ITU-T last call) and is described in draft-tsb-mpls-tp-ach-ptn. Regards, Malcolm Brian E Carpenter brian.e.carpen...@gmail.com Sent by: ietf-boun...@ietf.org 05/10/2011 04:16 PM To yang.jia...@zte.com.cn cc m...@ietf.org m...@ietf.org, D'Alessandro Alessandro Gerardo alessandro.dalessan...@telecomitalia.it, ietf@ietf.org ietf@ietf.org, larryli...@yahoo.com.cn, mpls-bounces@ietf.orgLarry, adr...@olddog.co.uk adr...@olddog.co.uk 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 Hi Jian, On 2011-10-06 03:53, yang.jia...@zte.com.cn wrote: Dear All, I do not support either. In section 3.5: If two MPLS OAM protocols were to be deployed we would have to consider three possible scenarios: 1) Isolation of the network into two incompatible and unconnected islands. Two OAM solutions have been discussed for a long time in both ITU-T and IETF. Each solution has their own supporters inculding carriers and vendors. So I don't think there is any interworking issue between two OAM solutions. Carrier will select one OAM solution, A or B, in their network. No need to select A and B at one network at the same time. There are two large costs that you are ignoring: a) all vendors wishing to bid for business from A and B will have to implement and support both solutions. b) when A buys B or B buys A, the incompatible networks will have to be merged. These are costs that run to hundreds of millions of USD, EUR or CNY. They are costs caused directly by SDOs creating rival solutions. I think it would be irresponsible of the IETF not to document this situation. As engineers, we have an ethical responsibility here. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] 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
Rui, Excellent point, I fully agree, we need to focus on the 99% that is identical and not cause the 1% that is different (for good reasons) to cause a rift that will drive further divergence. Regards, Malcolm Rui Costa rco...@ptinovacao.pt Sent by: ietf-boun...@ietf.org 05/10/2011 11:06 PM To ietf@ietf.org ietf@ietf.org cc Subject RE: [mpls] 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 Sometimes when two worlds come together, you don't get common standards right away. For the SONET/SDH example, it has been pointed out that starting from digital voice, we had different regions of the world choosing A-law or mu-law encoding, then 24-channel vs 30-channel PDH hierarchies. SONET and SDH evolved originally as optimized transport for the 24-channel and 30-channel hierarchies, but we were able to push them into common physical layer interfaces for the various bit-rates, and today what we call SDH is really a superset of the two multiplexing hierarchies, so the same box can be sold anywhere in the world and can be configured to support the hierarchy of the local network. When data friendly features were added to SONET/SDH (VCAT, GFP, LCAS), these were defined once and not in multiple regional variants. When we finally reached OTN, we were able to agree to develop a single, global standard from the start. For MPLS-TP, we have the coming together of the transport world with the Internet world. We have succeeded in driving together many aspects of this technology, but we shouldn't be too surprised that we can't get down to one variant in the very first try at bringing these together. Regards, Rui -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: segunda-feira, 26 de Setembro de 2011 22:58 To: m...@ietf.org Subject: [mpls] 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 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 -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: 26 September 2011 20:43 To: IETF-Announce Subject: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM' draft-sprecher-mpls-tp-oam-considerations-01.txt as an Informational RFC 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-10-24. 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 The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology for use in transport network deployments. That is, MPLS-TP is a set of functions and features selected from the wider MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks. During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment. One major set of additions provides enhanced support for Operations, Administration, and Maintenance
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Brian, Thank you for your constructive suggestion. I will attempt to start a discussion on a new thread in a few days - I am currently travelling with very limited time windows when I can access the Internet. Regards, Malcolm Brian E Carpenter brian.e.carpen...@gmail.com 06/10/2011 03:47 PM To malcolm.be...@zte.com.cn cc adr...@olddog.co.uk adr...@olddog.co.uk, ietf@ietf.org ietf@ietf.org, m...@ietf.org m...@ietf.org Subject Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Malcolm, I'm technically incompetent to comment on draft-tsb-mpls-tp-ach-ptn. However, if we reframe the debate as how to reconcile OaM for Ethernet-based PTN with OaM for MPLS-TP-based PTN, we might have a more productive discussion. Regards Brian Carpenter On 2011-10-07 03:00, malcolm.be...@zte.com.cn wrote: Brian, The second solution already exists, (300,00+ nodes already deployed - see other emails on this thread). We must acknowledge this and find the most cost effective way of allowing interconnection. That is best achieved by recognizing the Ethernet tool set based solution and defining interconnection such that an interworking function is not required. This has already been proposed and documented in draft revised Recommendation G.8110.1 (now in ITU-T last call) and is described in draft-tsb-mpls-tp-ach-ptn. Regards, Malcolm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Rolf, I agree with the points that you have raised, we need to make more efficient use of our time to address the real technical issues. To expand on this point, one major factor that has not been considered in this draft is that significant deployments (300,000+ nodes) of a second solution already exist. This second solution is based on the Ethernet tool OAM tool set, see draft-fang-mpls-tp-oam-considerations for further details. Given the current situation the pragmatic engineering approach is to: - Acknowledge these deployments: - Define a method for interconnecting between domains that deploy the tools identified in draft-ietf-mpls-tp-oam-analysis and the Ethernet based tool set that avoids the need for an interworking function: - Take steps to avoid a proliferation of further options (i.e. a third of fourth or nth solution). I do not want to expend energy on debating how we arrived at this situation, its document on various email threads and in Internet drafts. History has shown that we all have our own interpretation of these events and repeating this debate is unlikely to cause the protagonists to change their opinions. We need to focus on how we manage the situation in which we find ourselves. Regards, Malcolm Rolf Winter rolf.win...@neclab.eu Sent by: ietf-boun...@ietf.org 05/10/2011 10:52 AM To Loa Andersson l...@pi.nu cc ietf@ietf.org ietf@ietf.org Subject RE: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM)to Informational RFC Hi Loa, There actually are some nuggets in the document but you have to look hard for them. E.g. section 4.2 analyzes TDM PWs and states that even within the IETF the exact same situation has arisen before, and three solutions have been specified. However, the IETF made one of them the default solution, so at least there is a baseline type to use and interoperability is guaranteed. If the IETF has gone down that particular path, then I don't see a reason why we cannot do the same thing again (yes, yes I know it is not optimal, I wish life was simple but I was recently convinced of the opposite). The document makes another good point in this regard: the party that is not using the default needs to bear all the cost (operational and such) which is a good point to make. This whole situation right now feels like some sort of attrition warfare and I don't think it is efficient use of our time. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: Loa Andersson [mailto:l...@pi.nu] Sent: Mittwoch, 5. Oktober 2011 13:51 To: Rolf Winter Cc: ietf@ietf.org Subject: Re: Last Call: draft-sprecher-mpls-tp-oam-considerations- 01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Rolf, I don't remember saying the sole purpose, the IETF way is to document requirements, specifications, processes and agreements in RFCs; this is just another document in this tradition. ANd as such a very good document. /Loa On 2011-10-05 13:31, Rolf Winter wrote: Hi Loa, Let me answer with a counter-question. If the sole purpose of this document is to stop the development of two OAM solutions, do you think this RFC-to-be will achieve that? Seriously? The problem I see here is that we start a habit of writing politically motivated documents. We have this issue documented already all over the place in the form of minutes, web sites, press releases etc. I think this is enough and the right place. Let the I* and liaisons figure this out so that we all can go back to protocol design and development. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: Loa Andersson [mailto:l...@pi.nu] Sent: Mittwoch, 5. Oktober 2011 12:48 To: ietf@ietf.org; Rolf Winter Subject: Re: Last Call:draft-sprecher-mpls-tp-oam-considerations- 01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Rolf, are you saying that if we just liaise RFC1958 to the ITU-T they will stop developing a competing OAM for MPLS? Sometimes the life is simple, though I doubt that it is this simple. My 2c's is that this a good draft and should be progressed. /Lao On 2011-10-04 11:16, Rolf Winter wrote: Hi, I think Brian makes an excellent point here. RFC 1958 already contains exactly the same basic message (just with far less (unnecessary) words). I don't think we need this document as it doesn't really add anything to what RFC 1958 says. I'll provide a more detailed review later. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Brian, I think that points that Huub is raising are: a) The text quoted from page 113 RFC 5317 the architecture allows for a single OAM technology for LSPs, PWs is being used as (part of) the rational for only having a single OAM solution, however page 12 of RFC 5317 states that the subsequent slides represent an agreed starting point for the work. b) The IETF have developed two different solutions, one for LSP and another for PWs and this confirms that the quoted text was just a starting point. I agree with you that, in some cases for good reasons, more than one solution is developed and deployed. Regards, Malcolm Brian E Carpenter brian.e.carpen...@gmail.com Sent by: ietf-boun...@ietf.org 30/09/2011 03:47 PM To huubatw...@gmail.com cc ietf@ietf.org Subject Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM)to Informational RFC Huub, On 2011-09-30 20:19, Huub van Helvoort wrote: All, Section 1,1 also contains the text: [RFC5317] includes the analysis that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. This is a quote from slide 113 in the PDF version of RFC5317 and should be read in realtion to the statement on slide 12 of the same RFC: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the *agreed upon starting point* for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements So the quoted text in the draft is one of the assumptions. The fact that there are currently *two* OAM mechanisms (and not a *single*), i.e. one for PW and one for LSP proves that the assumption was not correct. I'm sorry, I don't understand your logic. You seem to be saying that the fact that two solutions have been designed proves that the assumption that a single solution is possible was false. That doesn't follow at all. The engineering profession has a long history of producing multiple solutions where a single one was possible, and this seems to be just another such case. This isn't news. I quote from RFC 1958 (June 1996): 3.2 If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
All, From my personal knowledge, the comments from Huub are accurate. (I was an active participant at the 1988 ITU meeting in Seoul where the SDH frame format was agreed). The IETF should not publish a consensus approved draft that contains inaccurate information about a standard that was developed outside the IETF. The gross inaccuracy in the characterization of SONET/SDH leads me to question the validity of the document. Regards, Malcolm Huub van Helvoort huubatw...@gmail.com Sent by: ietf-boun...@ietf.org 29/09/2011 02:00 AM Please respond to huubatw...@gmail.com To ietf@ietf.org cc Subject Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC All, Why section 5.1 is an author's impression: Statement: SONET and SDH were defined as competing standards Fact: SONET was developed first by ANSI based on the 24 channel PDH hierarchy existing in North America and Japan. The basic rate based on DS3. Some time later ETSI developed SDH based on the 30 channnel PDH deployed in Europe. The basic rate based on E4 (3x DS3). To be able to deploy SONET and SDH worldwide the regional SDO experts came together in ITU-T to define a frame structure and a frame-rate that would allow interconnection of SONET and SDH. A compromise was agreed and approved in an ITU-T meeting in Seoul in 1988. Statement: Significant confusion resulted from this situation. Fact: The result of the compromise is documented in ITU-T recommendation G.707 which includes the frame definition and frame-rates, and documents how SONET and SDH can interconnect. Statement: Equipment manufacturers needed to select the market segment they intended to address. The cost of chipsets for a limited market increased. Fact: Most equipment vendors did/do sell their equipment in both regions. I was involved in chip designs for SONET/SDH in several companies, they all support SONET and SDH in a single chip, and the selection is a matter of provisioning, the addition cost to support both was minimal (single chip: higher volume = lower cost) Statement: Service providers needed to consider the merits of the two standards and their long-term role in the industry when examining their investment options. Fact: Because the regions or applicability of SONET and SDH are well known SPs do not have to make this consideration. Statement: Only a limited number of equipment manufactures were available for selection. Question: What do you consider a limited number? Statement: As SONET was considered to be the variant, interworking had to be performed before the SDH-based segment was reached. Fact: SONET is *NOT* a variant it is equivalent to SDH. The reason for placing the interconnection functionality on the SONET side was that in a previous agreement on interconnection the functionality was placed on the European side. Conclusion: There is a single frame structure used by both SONET and SDH. This is documented in ITU-T recommendation G.707 (ANSI and ETSI still have their SONET resp. SDH standard available in their own documentation, but they are aligned with G.707). It depends on the application of the frame structure in an environment with 24 channel legacy PDH to call it SONET and in an evironment with 30 channel legacy PDH to call it SDH. The meeting in Seoul in 1988 shows that SDOs can compromise to find a common frame structure that can be used in different regions/applications. Best regards, Huub. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Tom, Please see in line below. Regards, Malcolm Thomas Nadeau tnad...@lucidvision.com Sent by: ietf-boun...@ietf.org 29/09/2011 07:48 AM To huubatw...@gmail.com cc The IESG iesg-secret...@ietf.org, ietf@ietf.org, IETF-Announce ietf-annou...@ietf.org Subject Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM)to Informational RFC On Sep 29, 2011, at 1:06 AM, Huub van Helvoort wrote: All, I propose to completely remove section 5 of this draft. The reason: The IETF should *NOT* document any comment on any multiple standards developed by other SDOs which are outside of the IETF's scope. Especially standards like like SONET/SDH, CDMA/GSM. The current text reflects the author's impressions, and since I don't believe that the authors were involved in the debates when these standards were developed, they *DO NOT KNOW ENOUGH* to comment authoritatively on them. Isn't that why this draft is targeted as an *individual and informational* draft? Since that is the case, I don't see how your point is relevant to the document at hand. [MB] The last call is for consensus approval by the IETF so this draft, if published, will be the opinion of the IETF. Therefore the point raised by Huub is relevant. The IETF should refrain from documenting things that might offend other SDOs concerning standards issues in which IETF was or is not involved. That is your opinion. However, please observe that other SDOs document and cross-reference each others' works all the time often adding their 2 cents. For example, take what the BBF does with many IETF standards. [MB] Big difference between referencing the work of another SDO from a standard and issuing a standard that make inaccurate comments about a standard that was developed in another SDO. --Tom Best regards, Huub. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Tom, Please see in line below. Regards, Malcolm Thomas Nadeau tnad...@lucidvision.com Sent by: ietf-boun...@ietf.org 29/09/2011 09:18 AM To huubatw...@gmail.com cc The IESG iesg-secret...@ietf.org, ietf@ietf.org, IETF-Announce ietf-annou...@ietf.org Subject Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM)to Informational RFC A few more thoughts on this thread. All, I propose to completely remove section 5 of this draft. The reason: The IETF should *NOT* document any comment on any multiple standards developed by other SDOs which are outside of the IETF's scope. Especially standards like like SONET/SDH, CDMA/GSM. The current text reflects the author's impressions, and since I don't believe that the authors were involved in the debates when these standards were developed, they *DO NOT KNOW ENOUGH* to comment authoritatively on them. Why do you suddenly think that it is important for only people with knowledge of a topic to contribute to standards? Where does that leave the ITU-T's input on MPLS? I can give you many examples of where people who had no qualification as experts in a particular field have contributed to standards, but I will refrain from doing so so as to not offend other SDOs as you say below. 8) [MB] This individual draft is now in IETF last call. At this stage it should represent the opinion of those who are experts in the field. Clearly during the development of a draft all interested participants, expert or not, should provide input. Best regards, Huub. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
