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, I support Yoshinori's words. 1 solution is better than 2, but 2 are better than 3, 4, 5... MPLS is a standard, a language, not a product, like f.i. MPLS/IP routers are. The word Oi, present in a modern Portuguese dictionary, wasn't crafted in Portugal but in Brazil. Although Portugal was the origin of the language, we're just a fraction of the worldwide Portuguese speaking community. A standard is more pragmatic than a language. I can't imagine Rivest, Shamir or Adleman feeling interfered but proud, when IETF used RSA public key cryptography in SSL/TSL. Possibly, when typing https, nobody remembers Fermat's little theorem and its Euler's extension, where RSA is grounded but, if they were alive, they would surely also be proud. By starting T-MPLS, to serve those wishing an SDH/OTN flavored packet technology, ITU-T actually followed RFC1958. (If a previous design, in the Internet context or elsewhere, has successfully solved the same problem [...].) It isn't a so complexity/features enamored baroque view but more KISS aiming. And this cultural background difference is perhaps a major cause for confusion between the 2 views under discussion. No one has doubts about IETF as MPLS creator and certainly MPLS creators do have a word when someone suggests extending their work, but killing primary goals like OAM simplicity kills that view, questioning all this work. ITU-T accepted IETF expertise and MPLS-TP project, although that would delay the Recommendations (3 years up to now), constructively proposed the development of 2 solutions, when it became clear that their supporting communities wouldn't change their minds. Although i respect the draft's authors' view, as well as their supporters', i can't agree with its publication: it's a partial view and just another tool of not constructively killing an equally important view's primary goals. It's time to build and let others build. Best Regards, Rui -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Yoshinori Koike Sent: terça-feira, 25 de Outubro de 2011 07:06 To: 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, I would like to appreciate the editors' efforts to try to examine the consequences of the existence of two MPLS-TP OAM solutions, however I don't understanding the meaning to publish this draft at this stage. I agree that one solution is desirable described. However, considering the extraordinary efforts made by IETF and ITU-T, this case corresponds to an unavoidable case which is described in RFC1958. That is, both OAM solutions(G.8113.1 and G.8113.2) are worth being standardized. Positive sides of having the second solution should be valued more in terms of further development of MPLS-TP technology rather than the negative sides such as complexity. The followings are the reasons that I stated above. 1) In general, both OAM solutions(G.8113.1 and G.8113.2) seem to be supported by two different large communities of interest internationally. Therefore, standardization of both OAM solutions will be best choice for the future development of MPLS-TP technology, which I believe is a common goal/wish for both communities. 2) A lot of operators/users have been waiting for the MPLS-TP standards for a long time, since MPLS-TP work started. Generally, no one doubt that one solution for one functional requirement is best as mentioned in this draft. As a result, in my understanding, a lot of efforts have been made to achieve the goal for about 3-4 years by IETF and ITU-T, but the consequence is what we are facing now. It should be seriously considered that the current status is the result of extraordinary efforts. Accordingly, limiting the solution only one (publishing the this draft) at this stage doesn't seem to be reasonable, because all the efforts made by experts in both parties (IETF and ITU-T) are enough to be respected. 3) It is true that MPLS-TP is a MPLS technology. It is also true that MPLS-TP is a transport technology. What I learned so far is that both technologies possess their own histories, experiences and established reliabilities in OAM solutions (G.8113.2(BFDLSP ping based) and G.8113.1(Ethernet-based OAM) and very hard to radically change their assets. If I quote the good expression from the draft, each side wishes a soft transition rather than a cliff. 4) MPLS-TP is a joint work which has a great potential to create future innovative MPLS-based transport networks for operators/users. But, I think they will never be achieved without collaboration. 5) I understand the difficulties and complexities which were described in this draft, but I believe it's worth challenging for both implementers and operators. 6) There are a number of positive sides by containing the G.8113.1(Ethernet-based OAM)
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, I would like to appreciate the editors' efforts to try to examine the consequences of the existence of two MPLS-TP OAM solutions, however I don't understanding the meaning to publish this draft at this stage. I agree that one solution is desirable described. However, considering the extraordinary efforts made by IETF and ITU-T, this case corresponds to an unavoidable case which is described in RFC1958. That is, both OAM solutions(G.8113.1 and G.8113.2) are worth being standardized. Positive sides of having the second solution should be valued more in terms of further development of MPLS-TP technology rather than the negative sides such as complexity. The followings are the reasons that I stated above. 1) In general, both OAM solutions(G.8113.1 and G.8113.2) seem to be supported by two different large communities of interest internationally. Therefore, standardization of both OAM solutions will be best choice for the future development of MPLS-TP technology, which I believe is a common goal/wish for both communities. 2) A lot of operators/users have been waiting for the MPLS-TP standards for a long time, since MPLS-TP work started. Generally, no one doubt that one solution for one functional requirement is best as mentioned in this draft. As a result, in my understanding, a lot of efforts have been made to achieve the goal for about 3-4 years by IETF and ITU-T, but the consequence is what we are facing now. It should be seriously considered that the current status is the result of extraordinary efforts. Accordingly, limiting the solution only one (publishing the this draft) at this stage doesn't seem to be reasonable, because all the efforts made by experts in both parties (IETF and ITU-T) are enough to be respected. 3) It is true that MPLS-TP is a MPLS technology. It is also true that MPLS-TP is a transport technology. What I learned so far is that both technologies possess their own histories, experiences and established reliabilities in OAM solutions (G.8113.2(BFDLSP ping based) and G.8113.1(Ethernet-based OAM) and very hard to radically change their assets. If I quote the good expression from the draft, each side wishes a soft transition rather than a cliff. 4) MPLS-TP is a joint work which has a great potential to create future innovative MPLS-based transport networks for operators/users. But, I think they will never be achieved without collaboration. 5) I understand the difficulties and complexities which were described in this draft, but I believe it's worth challenging for both implementers and operators. 6) There are a number of positive sides by containing the G.8113.1(Ethernet-based OAM) solution. -It seems that the integrity of control plane protocol on the OAM solution (G.8113.1) can be maintained as seen in ASON GMPLS relationship. If necessary, it might be easy to apply the control plane to Ethernet OAM configuration. -Expanding Carrier Ethernet based on Ethernet OAM is considered to be one of the major traffics for future MPLS-TP transport networks. The OAM solution(G.8113.1) can alleviate the anxiety of some operators who would like to migrate their networks with soft transition from Ethernet/SDH networks, because those operators/users have doubt about the feasibility of having the similar operational experiences with transport network OAM(covered by Ethernet OAM) by applying G.8113.2(BFD based) OAM. This will increase the opportunity of the deployment of MPLS-TP. -Lately, both Ethernet OAM and MPLS-TP OAM tend to be implemented in one box (equipment) to flexibly respond to the uses needs. In this kind of product, the complexity of implementation will be mitigated. Best regards, Yoshinori -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
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, Please publish this RFC ! It is an important statement of the single solution principle in the IETF. On Sep 28, 2011, at 4:02 AM, Brian E Carpenter wrote: Please see attached review. draft-sprecher-mpls-tp-oam-considerations-01-carpenter.txt___ 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
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-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
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 have taken the time to read this document and support it's publication. From an operational PoV, the discussion in the Section 3 (particularly Sections 3.5 3.6) really hit home in that the costs of deploying a protocol to the network _and_ maintaining that protocol in the network are non-trivial. And, ultimately, for a function as critical as OAM it absolutely needs to just work *everywhere*. -shane 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 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
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
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 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
I have taken the time to read this document and support it's publication. From an operational PoV, the discussion in the Section 3 (particularly Sections 3.5 3.6) really hit home in that the costs of deploying a protocol to the network _and_ maintaining that protocol in the network are non-trivial. And, ultimately, for a function as critical as OAM it absolutely needs to just work *everywhere*. -shane 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
R: [mpls] R: Re: 答复: 回复： 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
John, I often appreciate Erminio's comments on this mailing list but I had not till now the pleasure to meet him because he does not attend the IETF meetings. At my knowledge, I'm the only Alessandro that has been following MPLS-TP standardization process and apparently it seems to me you want to associate Erminio's comments to me (in your email below). I regret to tell you that I follow standards on behalf of TI and exclusively for the interest of my Company. I have therefore no need to use an informal email account (and I'll never do it). Best regards, Alessandro -- Telecom Italia Alessandro D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -Messaggio originale- Da: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] Per conto di John E Drake Inviato: mercoledì 19 ottobre 2011 23:55 A: erminio.ottone...@libero.it; brian.e.carpen...@gmail.com; yang.jia...@zte.com.cn Cc: m...@ietf.org; mpls-bounces@ietf.orgLarry; ietf@ietf.org Oggetto: RE: [mpls] R: Re: 答复: 回复： 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 Alessandro, Apparently, the advice given regarding the risks and costs associated with deploying proprietary or pre-standard solutions didn't resonate with you. Do you really expect the rest of us to clean up after you? Thanks, John -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of erminio.ottone...@libero.it Sent: Wednesday, October 19, 2011 1:49 PM To: brian.e.carpen...@gmail.com; yang.jia...@zte.com.cn Cc: m...@ietf.org; mpls-bounces@ietf.orgLarry; ietf@ietf.org Subject: [mpls] R: Re: 答复: 回复： 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 If the MPLS WG had selected the OAM solution that was already existing (as indicated multiple times by the operators which have already massively deployed it), we would have had a single OAM solution both in the market and in the IETF RFCs. We now have two OAM solutions: one (which is not actually really singular) documented by IETF RFCs and one widely implemented and deployed. This draft is not resolving this issue at all. Messaggio originale Da: brian.e.carpen...@gmail.com Data: 5-ott-2011 22.16 A: yang.jia...@zte.com.cn Cc: m...@ietf.orgm...@ietf.org, ietf@ietf.orgietf@ietf.org, mpls- bounces@ietf.orgLarry Ogg: Re: [mpls] 答复: 回复： R: FW: Last Call: lt;draft-sprecher- mpls-tp-oam- considerations-01.txtgt; (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 ___ 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying,
RE: [mpls] R: Re: 答复: 回复： 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
Alessandro, Apparently, the advice given regarding the risks and costs associated with deploying proprietary or pre-standard solutions didn't resonate with you. Do you really expect the rest of us to clean up after you? Thanks, John -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of erminio.ottone...@libero.it Sent: Wednesday, October 19, 2011 1:49 PM To: brian.e.carpen...@gmail.com; yang.jia...@zte.com.cn Cc: m...@ietf.org; mpls-bounces@ietf.orgLarry; ietf@ietf.org Subject: [mpls] R: Re: 答复: 回复： 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 If the MPLS WG had selected the OAM solution that was already existing (as indicated multiple times by the operators which have already massively deployed it), we would have had a single OAM solution both in the market and in the IETF RFCs. We now have two OAM solutions: one (which is not actually really singular) documented by IETF RFCs and one widely implemented and deployed. This draft is not resolving this issue at all. Messaggio originale Da: brian.e.carpen...@gmail.com Data: 5-ott-2011 22.16 A: yang.jia...@zte.com.cn Cc: m...@ietf.orgm...@ietf.org, ietf@ietf.orgietf@ietf.org, mpls- bounces@ietf.orgLarry Ogg: Re: [mpls] 答复: 回复： R: FW: Last Call: lt;draft-sprecher- mpls-tp-oam- considerations-01.txtgt; (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 ___ 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: 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 Yaakov, You wrote 16 October 2011 10:46 To: Harrison,N,Neil,DKQ7 R; huubatw...@gmail.com; ietf@ietf.org Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon) 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 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. Indeed, to have any peer to peer OAM simply removes the ability of the OAM to do its job. Neither of these statements is completely accurate. NH= Actually the latter is if the OAM is to do its job to the most simple/optimal/reliable levelbut we can of course ignore and overrule such a requirement. For example, the ITU produced Y.1712 that details the peer-peer interworking of ATM OAM per I.610 with the MPLS OAM described in Y.171. NH= Indeed so. Dave Allan and I wrote Y.1712. I only realised later what a waste of time it was...and on 2 counts: - Andy Reid made me aware of just what a bad and unnecessary idea an AIS/FDI signal was in a co-ps mode layer network (its obviously silly for a cl-ps mode layer network); - I sat down and thought much more deeply about what peer interworking really means... noting that DP OAM I/W is only one small facet of the whole DP/CP I/W vista anyway. The key revelation for me was understanding that since the whole purpose of *all* networking scenarios is to allow message/file/stream applications that are external to the network(s) to communicate over large geographic distance, then the only place peer I/W is of any relevance is in the TOS layer networks (like IP, the PSTN and (potentially) ATM) that have the required message/file/stream external application adaptations functions. Any non-TOS layer peer I/W (and this is for all the DP/CP components, not just the DP OAM bit) is just generating unnecessary work/problems/costs for the sake of it...because we still need to terminate the non-TOS layer network(s) and expose the real E2E TOS layer network case that must always be present! Simple and blindingly obvious when pointed out. I wrote a paper on thi s that goes into a little more detail. I'll send you a copy of it if you like...just ask. Note - The physical interconnection of BOS guided EM wave media (metallic or optical) components is *not* peer I/W. This is how we physically plug together different boxes at the BOS. Here we are only interested (for many reasons) in the transparent transfer of the DP symbols. I think that the accurate statement is that OAM interworking is perhaps undesirable but trivial when the OAM semantics matches so that the interworking is syntactic translation, but very challenging (and perhaps sometimes impossible) when the semantics are different. (For semantics to be different it is enough for timer values to be different, let alone different fault states.) NH= This is true. When Dave/I penned Y.1712 our main thought was we could sensibly do this because of the close alignment of the OAM. Only later did I fully realise what a waste of time doing this was anyway. But you are right that peer interworking becomes even more daft/harder when we have (in increasing order of daftness/hardness): (i) the same mode but quite different DP/CP functional specifications in each technology (wrt traffic unit structure and fields therein, addressing of access points, routing, signalling, OAM, etc...all these components must be interworked) or (ii) different modes...here we can have very significant functional mismatch, and some functions simply don't exist or align at all, eg - co-cs/ps signalling (esp OOB) is not relevant to the cl-ps mode - co-cs DP AIS/FDI is obviously not relevant to the cl-ps mode and (less obviously so) to the co-ps mode - a cl-ps mode traffic unit TTL function should never appear in a co-cs or co-ps mode layer network traffic unit - the short-cuts in traffic unit labelling that can be applied to the co-ps and co-cs modes (they are not the same) cannot be applied at all to the cl-ps mode - etc. However, there are many cases where several OAM types co-exist in a single deployment. Perhaps the most relevant case is the widespread use of both EFM OAM (802.3 Section 57) with Y.1731 OAM. NH= Of course we can this...just like we can do all sorts of wrong/unnecessary things. The key issue with co-ps mode OAM of course is that when it arrives at any DP trail termination point that trail termination point must be able to make sense of it if we are not only to detect misconnectivity but diagnose the offending source. If there are N spins of OAM in some layer network then each trail termination point needs to be able to handle N types of OAM arriving due to misconnectivity. This is hardly a sensible situation to allow to happen however.
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
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. Indeed, to have any peer to peer OAM simply removes the ability of the OAM to do its job. Neither of these statements is completely accurate. For example, the ITU produced Y.1712 that details the peer-peer interworking of ATM OAM per I.610 with the MPLS OAM described in Y.171. I think that the accurate statement is that OAM interworking is perhaps undesirable but trivial when the OAM semantics matches so that the interworking is syntactic translation, but very challenging (and perhaps sometimes impossible) when the semantics are different. (For semantics to be different it is enough for timer values to be different, let alone different fault states.) However, there are many cases where several OAM types co-exist in a single deployment. Perhaps the most relevant case is the widespread use of both EFM OAM (802.3 Section 57) with Y.1731 OAM. Y(J)S ___ 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
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 too object to having too many politically motivated process drafts (in addition to having questions about the specific examples in the present draft). However, I am not sure that RFC 1958 helps to much here. The relevant part of 1958 is : 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. That is fine, but what if there are already two solutions (which is the case here) ? It don't see it in 1958, but the IETF tao has generally been to have one MUST mode and perhaps one or more MAY modes. RFC 4835 is a good example of how this is done. So I believe that this draft is stating something stronger than RFC 1958, and indeed stronger than the IETF tao usually requires. Y(J)S ___ 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
I have very strong doubts about all the issues mentioned in sections 4 and 5 I have comments on 4.2 TDM PWs, 4.3 Codecs, and 4.4 MPLS signaling protocols. For TDM PWs the IETF followed its tao of requiring one MUST mode (RFC 4553) and allowing 2 MAY modes (RFCs 5086 and 5087). However, far from being a resounding triumph, this meant that a method considered inadequate by all who really understood the issues was mandated, while too equally adequate alternatives became optional. So this example actually shows a negative aspect of the procedure. Regarding the Code issue, multiple proposals were submitted, and the resolution was to mold two of them into a new combined codec with pieces of each. So this example is not relevant at all. Regarding CR-LDP vs. RSVP, once again there were two pre-existing solutions, and it was decided not to do any new work on one of them. But this left us with 2 mandatory to implement protocols (LDP and RSVP-TE) rather than a decision for CR-LDP which would have left a single mandatory protocol. So this actually a counter-example to the tao of having a single mandatory mode. Y(J)S ___ 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
The IETF has a very long history of pushing back on multiple redundant solutions to the same problem. There are a great many cases of ADs, working group chairs, and others pushing quite hard to prevent multiple solutions when one would work fine. I haven't seen this in the OAM work so far. PWE's VCCV has 3 or 4 different channels (code named CC types) and 3 or 4 different OAM mechanisms (code named CV types). And each of these has several variants and most have several possible encapsulations. Similarly in the MPLS-TP work we have a large number of options. For example, draft-ietf-mpls-tp-on-demand-cv has 3 different encapsulations (LSP-ping UDP/IP packet in MPLS, LSP-ping packet in UDP/IP in GACh, and raw LSP-ping packet in GACh with a new channel type). Why is it that no-one seems to object to a plethora of possible options for anything except the inner-most payload format? Y(J)S ___ 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 - 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
Malcolm, seems that you have the problem claiming text refers to assumptions or discussion points, especially since the format of the text is clearly decision. /Loa On 2011-10-15 02:37, malcolm.be...@zte.com.cn wrote: 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:
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 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
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 - comment 2
All, I agree with the reply from Malcolm below and support his suggested text insertion. And repeat that slide 113 is a *summary*. The *single* refers to the GAL - G-Ach discussion with the *solution* on slides 19 and 20 and the observations in slides 21 and 22. Regards, Huub. === Malcolm replied: 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
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 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 Manager l...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards
[mpls] 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, I support the publication of the draft as an informational RFC. This is a good example of providing an avenue for debate and then agreeing to a consensus on single solution and documenting it as a reference. The debate in SDOs has been on for a long time and every time I only get one or two examples of how a provider has deployed the alternative solution and hence it becomes mandatory for all SDOs to comply. To me those are bad choices made by people cognizant of the issues. These are the risks you take when you deploy pre-standard technology and have to rip it or migrate to standards based technology. Just because one or two providers deployed it does not mean it becomes mandatory on the rest of the world. The last time I checked there are more than 500 providers in the world. One solution is all that is needed for an IOT and two solutions are very expensive from a vendor point of view and from a provider point of view. I am sure all vendors and providers agree. From a vendor point of view they are expensive to build and from a provider point of view managing two domains is not easy. Now, no one is stopping people from inventing another protocol that looks a lot like MPLS and behaves a lot like MPLS with better OAM characteristics and then standardizing that protocol. I will fully support that protocol except that it cannot be called MPLS. It is a new protocol. Regards, Azhar Sayeed Cisco Systems Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Raking over the ashes [Was: 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]
Hi, If we must... I cannot find section 1.1 or the text one OAM solution in the PDF version of RFC 5317. I think Loa meant Section 1.1 of draft-sprecher-mpls-tp-oam-considerations and its reference to RFC 5317 (not Section 1.1 of the RFC itself). 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 No, it didn't. It had the power to make recommendations. Those recommendations were accepted by both the IETF and the ITU-T. The ITU-T communicated its acceptance of the recommendations in a liaison to the IETF. This is documented in RFC5317 as: These JWT recommendations were accepted by ITU-T management [MPLS-TP1]. 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
How does the IETF put a big red warning sign on a document produced by another standards body? http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-07. Actual coloring of course is impossible. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 ___ 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: Last Call draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Snipped, comment inline You are making a point on which I picked earlier because it is stated in the document as well. In case there are multiple solutions, documenting, but at the same time discouraging the other one has happened before. Why is this not possible in this case? Make one the default, the other optional with a big red warning sign. Best, Rolf This is indeed possible in this case. It has been privately suggested multiple times, but I agree that this should have been publicly suggested as well (and thus I guess that I am publicly suggesting it now). Ross [JD] How does the IETF put a big red warning sign on a document produced by another standards body? ___ 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
+1 john --On Wednesday, October 12, 2011 06:11 +0200 Patrik Fältström pat...@frobbit.se wrote: On 11 okt 2011, at 22:53, Ross Callon wrote: I didn't mean to say that the IETF in general allows multiple solutions but I think it is accurate to say that the IETF has a less than 100% success rate of preventing multiple solutions. Correct. We are not perfect. I had four proposals for chat protocols when I was Apps AD. One of them was NOT XMPP which now later seems to be what people use. My take is that: - If there is one proposal for a standard, it is enough for that proposal to be technically sound - If there are two proposals (or more), i.e. a situation where the market is to choose between the multiple proposals that more or less solve the same problem, there is an additional constraint, and that is that the proposals do not interfere with each other So if one have more than one proposal on the table that all move forward, they must be technically sound AND also not interfere with each other. This 2nd requirement is something that is not as easy to resolve as people might think. And specifically (we see in the MPLS case), the bandwidth of the liaison connection between SDOs is not high enough to guarantee this. We learned that the hard way between W3C and IETF. Because of that the liaison coordination is only to resolve what SDO is managing the multiple proposals. It can not handle the synchronization between proposals. And this to me is a key issue the whole MPLS discussion. It is just plain wrong to try to manage all variants of multiple flavors of ice-cream across SDOs. And why I strongly have the view I have on what has gone wrong. Patrik ___ 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
Hi, This is good input and made me realize what I disliked in the document which made me oppose to its publication. People (rightfully) pressed on the significance of the document to be about a general principle - one solution to any given problem. The IETF, _without_ external help, has a history of going down this road. Nobody stood up to stop that. Nobody wrote such a document then. Why now? Turf war, not invented here syndrome? I think it doesn't really matter. What would make my opposition go away is if we could write a more general document in which we point our own failings in the past, take this current issue into consideration and make it clear - in general - that the IETF is committed to follow this general principle more strictly in the future. _That_ would be a useful document and one which I would support. And it would be good if we could have such kind of pushback for multiple solutions in the future. WG chairs can take this document, show it to their WG and say Guy s, this is a guiding IETF principle. Get your act together and come up with a single solution. We will not have two or more.. Just ranting about this particular case is not helpful with all the multi-solutions we have created ourselves. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Stephen Kent Sent: Montag, 10. Oktober 2011 21:41 To: 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 I support this doc, and concur with Stewart's comments. Contrary to what some have suggested, we sometimes (ofttimes?) have more than one standard for no good technical reason. Sometimes very large, competing companies back different standards for parochial reasons, to the detriment of consumers, service providers, etc. This appears to be one of those cases. Moreover, not opposing a two-standard approach sends a bad message, and encourages similar, bad behavior in the future. As the co-chair of PKIX, which has two standards for cert management (CMC and CMP), for exactly the bad reasons I cite above, I am intimately familiar with this sort of problem. I failed, in my role as PKIX co-chair, to prevent this in that WG. Let's not repeat that sort of mistake here. Steve ___ 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
Huub, you are partly right - slide 9 says that there are open issues. But at the last meeting with the JWT consensus on the *summary* was the issue. The questions was put explicitly. At that time no one voiced another opinion! /Loa On 2011-10-09 12:58, Huub van Helvoort wrote: Hello Russ, You write: RFC 5317 calls for one, and only one, protocol solution. At least that is how I read JWT Agreement. How the JWT report should be read is written on slide 9 in the PDF: 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 The most relevant text seems to be in Section 9: This text is one of the assumptions, that is why we wrote: *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. The OAM technology in this text refers to to way the OAM frames can be detected in a data-stream. The text you quote is from the summary section, it summarizes the slides 19 - 22: *MPLS-TP Major Solution Constructs* which address the GAL-GAch solution. We now have the GAL-GAch technology (RFC5586) to detect OAM frames and this technology will be used in PW and LSP, and enables the use of OAM in deeply nested networks. Since the publication of RFC 5317, the MPLS WG consensus continues to be that only one OAM solution should become a standard. All MPLS-TP OAM tools should comply with RFC5586. A service provider can now pick any set or sub-set of the available OAM tools and use them without fear to disrupt the internet. Looking at the current discussions, there is no consensus (yet) on whether we need a comprehensive set of OAM tools, or a very limited set of OAM tools. Best regards, Huub (JWT, Ad-Hoc, MEAD member). ___ 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
Huub van Helvoort wrote 09 October 2011 12:42 To: IETF Discussion 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. Indeed, to have any peer to peer OAM simply removes the ability of the OAM to do its job. regards, Neil 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
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
This is not actually correct. The IETF has a very long history of pushing back on multiple redundant solutions to the same problem. There are a great many cases of ADs, working group chairs, and others pushing quite hard to prevent multiple solutions when one would work fine. In the very many previous cases it was not necessary to write a document because the second (or third, or ...) solution was within the same standards body, and it was possible to either prevent publication, or publish the second solution as informational, or publish the second solution with a disclaimer up front saying some form of we recommend this other solution [add normative reference] which is the agreed IETF standard. Ross -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Rolf Winter Sent: Tuesday, October 11, 2011 3:51 AM To: Stephen Kent; 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, This is good input and made me realize what I disliked in the document which made me oppose to its publication. People (rightfully) pressed on the significance of the document to be about a general principle - one solution to any given problem. The IETF, _without_ external help, has a history of going down this road. Nobody stood up to stop that. Nobody wrote such a document then. Why now? Turf war, not invented here syndrome? I think it doesn't really matter. What would make my opposition go away is if we could write a more general document in which we point our own failings in the past, take this current issue into consideration and make it clear - in general - that the IETF is committed to follow this general principle more strictly in the future. _That_ would be a useful document and one which I would support. And it would be good if we could have such kind of pushback for multiple solutions in the future. WG chairs can take this document, show it to their WG and say Guy s, this is a guiding IETF principle. Get your act together and come up with a single solution. We will not have two or more.. Just ranting about this particular case is not helpful with all the multi-solutions we have created ourselves. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Stephen Kent Sent: Montag, 10. Oktober 2011 21:41 To: 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 I support this doc, and concur with Stewart's comments. Contrary to what some have suggested, we sometimes (ofttimes?) have more than one standard for no good technical reason. Sometimes very large, competing companies back different standards for parochial reasons, to the detriment of consumers, service providers, etc. This appears to be one of those cases. Moreover, not opposing a two-standard approach sends a bad message, and encourages similar, bad behavior in the future. As the co-chair of PKIX, which has two standards for cert management (CMC and CMP), for exactly the bad reasons I cite above, I am intimately familiar with this sort of problem. I failed, in my role as PKIX co-chair, to prevent this in that WG. Let's not repeat that sort of mistake here. Steve ___ 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
This is not actually correct. The IETF has a very long history of pushing back on multiple redundant solutions to the same problem. There are a great many cases of ADs, working group chairs, and others pushing quite hard to prevent multiple solutions when one would work fine. In the very many previous cases it was not necessary to write a document because the second (or third, or ...) solution was within the same standards body, and it was possible to either prevent publication, or publish the second solution as informational, or publish the second solution with a disclaimer up front saying some form of we recommend this other solution [add normative reference] which is the agreed IETF standard. as ops ad, i had to do that with cops randy ___ 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
Ross, See inline. This is not actually correct. The IETF has a very long history of pushing back on multiple redundant solutions to the same problem. There are a great many cases of ADs, working group chairs, and others pushing quite hard to prevent multiple solutions when one would work fine. I didn't mean to say that the IETF in general allows multiple solutions but I think it is accurate to say that the IETF has a less than 100% success rate of preventing multiple solutions. In the very many previous cases it was not necessary to write a document because the second (or third, or ...) solution was within the same standards body, and it was possible to either prevent publication, or publish the second solution as informational, or publish the second solution with a disclaimer up front saying some form of we recommend this other solution [add normative reference] which is the agreed IETF standard. You are making a point on which I picked earlier because it is stated in the document as well. In case there are multiple solutions, documenting, but at the same time discouraging the other one has happened before. Why is this not possible in this case? Make one the default, the other optional with a big red warning sign. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 ___ 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
I didn't mean to say that the IETF in general allows multiple solutions but I think it is accurate to say that the IETF has a less than 100% success rate of preventing multiple solutions. Correct. We are not perfect. In the very many previous cases it was not necessary to write a document because the second (or third, or ...) solution was within the same standards body, and it was possible to either prevent publication, or publish the second solution as informational, or publish the second solution with a disclaimer up front saying some form of we recommend this other solution [add normative reference] which is the agreed IETF standard. You are making a point on which I picked earlier because it is stated in the document as well. In case there are multiple solutions, documenting, but at the same time discouraging the other one has happened before. Why is this not possible in this case? Make one the default, the other optional with a big red warning sign. Best, Rolf This is indeed possible in this case. It has been privately suggested multiple times, but I agree that this should have been publicly suggested as well (and thus I guess that I am publicly suggesting it now). Ross ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
OAM Interworking [Was: 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 sed: 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. Can I just ask for some clarification of this. We have become accustomed to refer to various in-band protection mechanisms (such as G.8031, etc.) as OAM. Although I can't say I am happy with this description (I prefer n-band control plane) I can see how there is a close relationship with the OAM messages especially as far as triggers are concerned. If we allow that these protection mechanisms are a form of OAM, then you will be aware of the work in Question 9/15 on what is being called G.iwk. This is examining the interworking of a variety of protection mechanisms at domain boundaries. So I suppose my questions are: - Do you consider protection mechanisms part of OAM? - Do you consider peer OAM interworking to be different from the work in G.iwk (and to some extent G.873.2)? 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. Are you saying that coexistence is only about providing e2e services across mixed networks? When you say that Section 6 is totally irrelevant are you saying that there is no need to establish the various issues and concerns wrt coexistence? You are (I assume!) not saying that draft-tsb-mpls-tp-ach-ptn is totally irrelevant. It certainly seems to me that Section 6 reaches many of the same conclusions for e2e delivery of OAM as are found in draft-tsb-mpls-tp-ach-ptn: perhaps the main difference is that this draft shows its workings. Thanks, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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: 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
Are we now going to be subject to daily updates? -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Huub van Helvoort Sent: Sunday, October 09, 2011 7:42 AM To: IETF Discussion 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: 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]
Hello Malcolm, A similar statement is already included in draft-tsb-mpls-tp-ach-ptn-01 The statement I found interesting was about consensus reached in an ITU-T meeting. I don't find this recorded in the Internet-Draft you pointed to. I asked whether there is 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
I support this doc, and concur with Stewart's comments. Contrary to what some have suggested, we sometimes (ofttimes?) have more than one standard for no good technical reason. Sometimes very large, competing companies back different standards for parochial reasons, to the detriment of consumers, service providers, etc. This appears to be one of those cases. Moreover, not opposing a two-standard approach sends a bad message, and encourages similar, bad behavior in the future. As the co-chair of PKIX, which has two standards for cert management (CMC and CMP), for exactly the bad reasons I cite above, I am intimately familiar with this sort of problem. I failed, in my role as PKIX co-chair, to prevent this in that WG. Let's not repeat that sort of mistake here. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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]
Hello Adrian, You typed: 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? On October 6 a liaison was sent to the IETF, and the m...@ietf.org list with the subject: New Liaison Statement, LS332 - Consent of Recommendation ITU-T G.8113.2/Y.1372.2 - MPLS The liaison informs the IETF that on September 16 recommendation G.8113.2 was consented in a WP3 plenary meeting. In both the Beijing Q10 expert meeting where the consent was proposed and the WP3 plenary meeting where the consent took place, there were no objections. G.8113.2 is attached to the liaison and you can read in it: Scope of G.8113.2: == This Recommendation specifies the default mechanisms for user-plane OAM (Operations, Administration and Maintenance) in MPLS-TP networks to meet the MPLS-TP OAM requirements defined in [IETF RFC 5860]. It also specifies the MPLS-TP OAM packet formats, syntax and semantics of MPLS-TP OAM packet fields. An optional set of OAM tools based on G.8013/Y.1731 is described in G.8113.1/Y.1372.1. Annex B of G.8110.1 provides reference scenarios for the interconnection of domains that use the OAM mechanisms defined in this Recommendation and domains that normally use the OAM mechanisms defined in G.8113.1/Y.1372.1. In the Beijing ITU-T expert meeting it was also agreed to change the scope of G.8113.1 to align it with the scope of G.8113.2. Scope of G.8113.1: == This Recommendation specifies an optional set of mechanisms for data-plane OAM (Operations, Administration and Maintenance) in MPLS-TP networks to meet the MPLS-TP OAM requirements defined in [IETF RFC 5860]. It also specifies the MPLS-TP OAM packet formats, syntax and semantics of MPLS-TP OAM packet fields. The default set of OAM tools is described in [ITU-T G.8113.2]. The MPLS-TP OAM mechanisms described in this Recommendation are intended to be used in a Transport Network application described in Annex A of [ITU-T G.8110.1]. Annex B of [ITU-T G.8110.1] provides reference scenarios for the interconnection of domains using the OAM mechanisms defined in this Recommendation and domains using the OAM mechanisms defined in [ITU-T G.8113.2]. = So with this liaison LS332 the IETF was already officially informed about the consent and the fact that there is a default OAM toolset and an optional toolset. Regards, Huub. ___ 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
On 10/10/2011 08:41 PM, Stephen Kent wrote: As the co-chair of PKIX, which has two standards for cert management (CMC and CMP), for exactly the bad reasons I cite above, I am intimately familiar with this sort of problem. I failed, in my role as PKIX co-chair, to prevent this in that WG. Let's not repeat that sort of mistake here. As one of the more minor perpetrators of that CMP/CMC travesty, I completely agree with Steve that the PKIX WG (and not just nor even mainly the chairs) failed in this respect due to what some of the then major players perceived as being in their commercial interests. We've all, including all the main CMP/CMC proponents afaik, been regretting that outcome for over a decade at this stage and continue to find the situation problematic. (What's the relevant plural for mea cupla I wonder? ;-) While I've not yet read the document in the subject line, the CMP/CMC experience makes me at least generally opposed to standardising two ways of doing the same thing. S. ___ 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
On 2011-10-11 10:18, Stephen Farrell wrote: ... (What's the relevant plural for mea cupla I wonder? ;-) Nostra culpa, if you want a single fault owned by us. It's nostrae culpae for multiple faults by all of us. Perhaps it should be added to the Note Well. Brian ___ 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
Hello Russ, You write: RFC 5317 calls for one, and only one, protocol solution. At least that is how I read JWT Agreement. How the JWT report should be read is written on slide 9 in the PDF: 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 The most relevant text seems to be in Section 9: This text is one of the assumptions, that is why we wrote: *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. The OAM technology in this text refers to to way the OAM frames can be detected in a data-stream. The text you quote is from the summary section, it summarizes the slides 19 - 22: *MPLS-TP Major Solution Constructs* which address the GAL-GAch solution. We now have the GAL-GAch technology (RFC5586) to detect OAM frames and this technology will be used in PW and LSP, and enables the use of OAM in deeply nested networks. Since the publication of RFC 5317, the MPLS WG consensus continues to be that only one OAM solution should become a standard. All MPLS-TP OAM tools should comply with RFC5586. A service provider can now pick any set or sub-set of the available OAM tools and use them without fear to disrupt the internet. Looking at the current discussions, there is no consensus (yet) on whether we need a comprehensive set of OAM tools, or a very limited set of OAM tools. Best regards, Huub (JWT, Ad-Hoc, MEAD member). ___ 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
Hello Russ, You wrote: although the SONET discussion could be discarded. It is not only the SDH/SONET discussion that should be removed. I have very strong doubts about all the issues mentioned in sections 4 and 5, none of them are factual. Regards, Huub. ___ 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, 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
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: 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 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. B.R. Yuxia malcolm.be...@zte.com.cn 发件人: ietf-boun...@ietf.org 2011-10-09 21:27 收件人 huubatw...@gmail.com 抄送 ietf-boun...@ietf.org, IETF Discussion ietf@ietf.org 主题 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 ___ 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
Hi, I have concern about statement on section 9 in RFC5317 by Russ: 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. As I said in my previous email, it means use same architecture (GACH) for LSP and PW OAM not deduce only one OAM solution should become a standard, and this is no consensus in mpls group. for OAM analysis, which is captured in draft-ietf-mpls-tp-oam-analysis, it is still a draft. and in section 2 of RFC 5860 (Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks): The way in which those protocols are operated and the way in which a network operator can control and use the MPLS-TP OAM functions SHOULD be as similar as possible to the mechanisms and techniques used to operate OAM in other transport technologies. this requirement is not satisfied by RFCs published. I fully agree All MPLS-TP OAM tools should comply with RFC5586 and should satisfy with RFC5860, and provider can pick up subset of them. finally, I still don't support publish draft-sprecher-mpls-tp-oam-considerations-01.txt as RFC. B.R. Feng -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Huub van Helvoort Sent: 2011年10月9日 18:58 To: 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 Hello Russ, You write: RFC 5317 calls for one, and only one, protocol solution. At least that is how I read JWT Agreement. How the JWT report should be read is written on slide 9 in the PDF: 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 The most relevant text seems to be in Section 9: This text is one of the assumptions, that is why we wrote: *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. The OAM technology in this text refers to to way the OAM frames can be detected in a data-stream. The text you quote is from the summary section, it summarizes the slides 19 - 22: *MPLS-TP Major Solution Constructs* which address the GAL-GAch solution. We now have the GAL-GAch technology (RFC5586) to detect OAM frames and this technology will be used in PW and LSP, and enables the use of OAM in deeply nested networks. Since the publication of RFC 5317, the MPLS WG consensus continues to be that only one OAM solution should become a standard. All MPLS-TP OAM tools should comply with RFC5586. A service provider can now pick any set or sub-set of the available OAM tools and use them without fear to disrupt the internet. Looking at the current discussions, there is no consensus (yet) on whether we need a comprehensive set of OAM tools, or a very limited set of OAM tools. Best regards, Huub (JWT, Ad-Hoc, MEAD member). ___ 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
Speaking only as an individual, I also support publication of this document as an informational RFC. I agree with many comments that the SONET discussion in section 5.1 should be deleted, and I would suggest that all of sections 4 and 5 be deleted. I was involved in the controversy that created both IS-IS and OSPF (as well as in the significant cooperation on protocol details that was going on in the background at the same time) and I think that the section on IS-IS and OSPF is mostly correct (even if I would have worded some of it a bit differently). One change I would make to this section is changing more than doubles the cost of link state IGP maintenance and deployment to be doubles the cost of link state IGP maintenance. Also derive from the same root document should be derive from the same root technology. Of course if sections 4 and 5 are deleted then there is no need to make these minor corrections to section 4.1. Regarding Russ's comment ...only one OAM solution should become a standard. I might note that there is considerable precedent in the IETF for publishing one standard, but also publishing informational RFCs that document other solutions that were considered in the IETF effort and that have been deployed. There certainly are many cases of pre-standard or non-standard solutions being deployed (often before IETF standards were finished) and in these cases I have long felt that it is desirable to document what has been deployed. Ross -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Russ Housley Sent: Saturday, October 08, 2011 11:03 AM To: IETF 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
two small points, 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
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 OAM technology in this text refers to to way the OAM frames can be detected in a data-stream. During the JWT effort, I did not interpret the term OAM technology to be strictly limited to just the manner in which OAM frames are detected in the data-stream. I interpreted this in a broader sense. Looking at the current discussions, there is no consensus (yet) on whether we need a comprehensive set of OAM tools, or a very limited set of OAM tools. I don't understand this comment. We have requirements documents that have been agreed and published, and that carefully lay out a list of capabilities that need to be available. We need tools that fulfill these requirements. Perhaps I am not sure what distinction you make between comprehensive set of OAM tools versus limited set of OAM tools. Ross ___ 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
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
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
Dear Russ Housley, RFC5317 said: a single OAM technology for LSPs, PWs, and a deeply nested network. it means LSA OAM and PW OAM should be same, it means the OAM solution should be apply on both LSP and PW layer. From RFC5317 will not educe to one solution standard for mpls-tp oam conclusion. B.R. Feng -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Russ Housley Sent: 2011年10月8日 23:03 To: IETF 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
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
Re: [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
While it is not perfect, I too support publication... W On Oct 5, 2011, at 7:11 PM, David Sinicrope wrote: I concur with Dave's comment and support publication of the draft. Dave On Oct 5, 2011, at 7:06 PM, David Allan I david.i.al...@ericsson.com wrote: 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 ___ 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
Hi all, I concur with both parts of Dave's message :-( and support publication of the draft. I have an editorial/factual comment regarding Section 4.2 of the draft. Let's begin with the fact that SAToP (i.e. RFC 4553) is not a Draft Standard, it is a Proposed Standard RFC. Further, I am not sure that the relationship between SAToP and other TDM PW modes - CESoPSN (RFC 5086) and TDMoIP (RFC 5087) - is correctly described in Section 4.2 of the draft. At least neither RFC 5086 not RFC 5087 contain any explicit statements about SAToP as the MUST to implement protocol. My 2c, Sasha From: mpls-boun...@ietf.org [mpls-boun...@ietf.org] On Behalf Of David Allan I [david.i.al...@ericsson.com] Sent: Thursday, October 06, 2011 1:05 AM 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 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___ 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
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
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. or aiding or abetting it. +1 randy ___ 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, I do not support this draft. As Brian pointed out there is already RFC1958 which addresses the same issues. So any more time spent on this draft is wasted. Brian quoted from RFC1958: 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. Please note that the Y.1731 toolset already existed in 2006. So when this toolset was adapted (using MPLS headers in stead of Ethernet headers) it was already used and tested. This is in line with section 3.14 in RFC1958: 3.14 And perhaps most important: Nothing gets standardised until there are multiple instances of running code. In the meantime there are multiple instances: more than 300.000 nodes with equipment from different vendors. Regards, Huub. ___ 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
As do I -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of David Sinicrope Sent: Wednesday, October 05, 2011 7:11 PM To: David Allan I Cc: m...@ietf.org; ietf@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 I concur with Dave's comment and support publication of the draft. Dave On Oct 5, 2011, at 7:06 PM, David Allan I david.i.al...@ericsson.com wrote: 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 ___ 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: [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
the ietf, and i hope all sdos, are supposed to provide users with interoperable multi-vendor choice, not non-interoperable multi-standard incompatibility. from a sic year old broadside https://archive.psg.com/051000.ccr-ivtf.pdf The IETF’s vendor/market approach has engendered a ‘let the market decide’ culture. Instead of hard- thought, rigorous, and simple designs, every possible feature gets added and many competing proposals are approved. This last is like throwing spaghetti at the wall to see what sticks, an amusing tactic to everyone but the wall. The operators are the wall. And they pay capital cost and operational expense to deploy complex features which vendors market as needs to the users. And then everyone wonders why the margins went down and the prices stayed up. randy ___ 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
Jian, See in-line. -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of yang.jia...@zte.com.cn Sent: Wednesday, October 05, 2011 10:54 AM To: ietf@ietf.org; m...@ietf.org; mpls-bounces@ietf.orgLarry 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 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. Repeating more times does not make the argument becoming correct. It wasted a lot of people a lot of time. 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. Don't think anyone said they intended to keep each of their networks/islands stay forever isolated. Two solutions bring in additional inter-op complications is a fact. Respect their own selection and listen to their requirements, please. Fully respect individual provider's choice of technology, that is a separate matter from standards. We are talking about IETF requirements here. Which requirement stated in the RFCs are not satisfied by the singe OAM solution defined in IETF? Best regards, Jian Thanks, Luyuan Larry larryli888@ya hoo.com.cn 收件人 发件人:adr...@olddog.co.uk mpls-bounces@i adr...@olddog.co.uk, m...@ietf.org etf.orgm...@ietf.org, ietf@ietf.org ietf@ietf.org, D'Alessandro Alessandro Gerardo 2011-10-05 alessandro.dalessandro@telecomitalia. 19:51 it 抄送 主题 [mpls] 回复： R: FW: Last Call: draft-sprecher-mpls-tp-oam- considerat ions-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Dear all, So many multiple solution cases just show the way that the world and technology works. Killing a solution roughly brings more damage to the industry. Section 3.6 discusses the elements of the choice of solutions. Current application and deployment should be considered. In China Mobile, more than 330,000 PTN box are/will based on G.8113.1. TDM PW gives a good example. G.8113.1 based OAM is relative simple and mature and widely deployed and should be the standard. Best regards, Han Li --- 11年10月5日，周三, D'Alessandro Alessandro Gerardo alessandro.dalessan...@telecomitalia.it 写道： 发件人: D'Alessandro Alessandro Gerardo alessandro.dalessan...@telecomitalia.it 主题: [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 收件人: adr...@olddog.co.uk adr...@olddog.co.uk, m...@ietf.org m...@ietf.org, ietf@ietf.org ietf@ietf.org 日期: 2011年10月5日,周三,下午5:38 Dear all, I do not support. Basically I think it is superfluous dedicate an RFC to state it is better having one standard instead of two ones or many... for sure the lower are the variants the better is for the industry (one is the ideal). When two or more standards or de-facto standards exist it is because the problem they solve is not exactly the same, the way they solve the problem is optimized for different environments/boundary conditions (more efficient, more effective, etc). Therefore a single solution does not necessarily meet the different market requirements. It is fundamental to enter into the problem's details before making consideration about the best way to proceed (one solution, two solutions, multiple solutions) whilst the document clearly declares it does not want to make any technical evaluations. After more than three years of debates within the IETF and major unresolved technical concerns risen from some transport operators, the existence of this draft is by itself the sure sign that MPLS-TP OAM is a case where a single solution has not be found to meet all the different market requirements. Otherwise, why are we still discussing about it? Therefore we must be realistic and the lessons learned from the past should guide our decisions: if a solution cannot be found for satisfying all the requirements
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: [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
Yes/support Regards, Jeff 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 ___ 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: 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. Please consider my comments as LC comments. Regards, Greg -- Forwarded message -- From: Greg Mirsky gregimir...@gmail.commailto:gregimir...@gmail.com Date: Mon, Oct 3, 2011 at 1:02 PM Subject: Comments to draft-sprecher-mpls-tp-oam-considerations To: ietf@ietf.orgmailto:ietf@ietf.org Dear Authors, please find my comments below: * page 9, first para s/we loose out/we lose out/ - two times * page 9, second to last para Partition of the network into incompatible and unconnected islands is neither desirable nor acceptable. While I agree with the former, the latter is highly subjective and absolutely unenforceable. As vendors we give operators loaded gun and a warning. What they do with them might surprise and amaze us all. * Section 4.4, first para: There are three MPLS signaling control protocols used for distributing labels to set up LSPs and PWs in MPLS networks: LDP, RSVP-TE, and GMPLS. Perhaps GMPLS in this list should be replaced by BGP/MPLS. RSVP-TE is equally used as signaling protocol to distribute MPLS and GMPLS label information. There are three paradigms that operate with distinct sets of constructs: * LDP MPLS, a.k.a. IP/MPLS; * TE-MPLS; * TE-GMPLS. * Section 4.4, second para. Would note that relationship between LDP and TE-(G)MPLS networks might be not only as peering but as client-server, e.g. LDP over RSVP-TE tunnels that could be MSPL-TP. Regards, Greg ___ 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
This document provides a factual and concise summary of work, events, and points of view that have developed since the JWT, a summary that's timely and sorely needed as few in the industry outside the project (or even inside the project) can make sense of it. It also provides a thorough and accessible analysis of the costs to service providers, vendors, the market, and the end user that divergent MPLS OAM solutions will create. As such, I think the IETF has a duty to move forward with its publication; the considerations it raises are of significant importance to the Internet community. It's also noteworthy that the proponents of a non-IETF MPLS OAM technology have been unwilling thus far to document the supposed technical problems with standard MPLS/MPLS-TP OAM in an Internet draft. If one didn't know better, one might be tempted to suppose their concerns were more political than technical. Following are LC comments/suggestions on the draft, all minor and editorial. --- Suggest adding a reference to RFC 5921 in first paragraphs of abstract/introduction. --- The terms inter-working and interworking both appear repeatedly throughout; it would be good to pick one. --- Section 1.1, 4th paragraph: s/which are applicable/that are applicable/ --- Section 1.1, last sentence: s/development and deployment making/development and deployment, making/ --- Section 1.2, 2nd paragraph: s/it was considered/it was judged/ --- Section 1.2, 3rd paragraph: OLD Indeed, one of the key differences between the two environments is the choice of MPLS-TP OAM solution which makes a circular argument. NEW Indeed, one of the key differences cited between the two allegedly distinct environments is the choice of MPLS-TP OAM solution, which makes a circular argument. END --- Section 1.2, next-to-last paragraph: s/normal IETF, consensus-driven/normal consensus-driven IETF/ --- Section 3.1, first paragraph: OLD In MPLS-TP, MPLS was extended to satisfy the transport network requirements in a way that was both compatible with MPLS as has already been deployed, and MPLS and with the IETF envisioned it would develop in the future. NEW In MPLS-TP, MPLS was extended to satisfy the transport network requirements in a way that was compatible both with MPLS as has already been deployed, and with MPLS as the IETF envisioned it would develop in the future. END --- Section 3.1, 2nd paragraph: s/philosophies that have lead/philosophies that have led/ --- Section 3.2, 2nd paragraph: OLD MPLS has been deployed in operational networks for approximately a decade, with the existing MPLS OAM techniques widely deployed in operational networks. NEW MPLS has been deployed in operational networks for approximately a decade, and the existing MPLS OAM techniques have seen wide deployment. END s/MPLS based/MPLS-based/ --- Section 3.3, first paragraph: s/can transition/can cross/ --- Section 3.3, 2nd paragraph: s/exiting network layer/existing network layer/ s/fast connectivity protocol/fast connectivity verification protocol/ --- Section 3.4, first paragraph: Second sentence needs rephrasing; maybe: OLD In an isolated system this may be the case, however when, as is usually case with communications technologies, simplification in one element of the system introduces a (possibly non-linear) increase in complexity elsewhere. NEW In an isolated system this may be the case. In an interconnected system such as a communications network, however, simplification in one element of the system may increase complexity elsewhere, and this increase may be non-linear. END --- Section 3.4, 2nd paragraph: OLD However, when we drive OAM complexity out of one network element at the cost of increased complexity at a peer network element we loose out economically and, more importantly, we loose out in terms of the reliability of this important network functionality. NEW However, when we drive OAM complexity out of one network element at the cost of increased complexity at a peer network element, there is no economic benefit and, more importantly, the reliability of the network is compromised. END --- Sections 4.1-5.3: Suggest expanding acronyms and adding references. --- Section 4.3, first paragraph: OLD Every time a new codec is deployed, translation between it and all other deployed codecs must be performed available within the network, each participating node must be able to handle the new codec. Translation between codec is expensive and can lead to reduced quality. NEW Every time a new codec is deployed, translation between it and all other deployed codecs must be performed within the network; codec translation is expensive and can lead to reduced quality. In addition, each participating node must be able to handle the new codec. END --- Section 4.3, 3rd paragraph: OLD The application layer of the Internet is, however,
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
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: [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
On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: major unresolved technical concerns Alessandro Please can I suggest that you write an internet draft detailing these major unresolved technical concerns so that we can all understand them. Such a draft needs to be technical, and describe the actions that the network operator is unable to perform, or the fault cases that they are unable to diagnose using the OAM defined in the IETF RFCs, or late stage WG drafts. Alternatively if you are referring to a bug in the MPLS-TP OAM protocols, you need to tell the community what it is. I believe that this request has been made a number of times, in various forums, and, as far as I know, no document has yet been produced. An argument of the form you must standardize what I want will not fly. What is needed is a very clear technical definition of the issue(s). When we have the major unresolved technical concerns on the table, we will be in a position to determine the best disposition of those issues. Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ 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, 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 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Freitag, 30. September 2011 21:48 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 -- 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
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 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Freitag, 30. September 2011 21:48 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 -- 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
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 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Freitag, 30. September 2011 21:48 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 -- 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 -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717
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 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Freitag, 30. September 2011 21:48 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
答复: [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
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. Respect their own selection and listen to their requirements, please. Best regards, Jian Larry larryli888@ya hoo.com.cn收件人 发件人:adr...@olddog.co.uk mpls-bounces@i adr...@olddog.co.uk, m...@ietf.org etf.orgm...@ietf.org, ietf@ietf.org ietf@ietf.org, D'Alessandro Alessandro Gerardo 2011-10-05 alessandro.dalessandro@telecomitalia. 19:51 it 抄送 主题 [mpls] 回复： R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerat ions-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Dear all, So many multiple solution cases just show the way that the world and technology works. Killing a solution roughly brings more damage to the industry. Section 3.6 discusses the elements of the choice of solutions. Current application and deployment should be considered. In China Mobile, more than 330,000 PTN box are/will based on G.8113.1. TDM PW gives a good example. G.8113.1 based OAM is relative simple and mature and widely deployed and should be the standard. Best regards, Han Li --- 11年10月5日，周三, D'Alessandro Alessandro Gerardo alessandro.dalessan...@telecomitalia.it 写道： 发件人: D'Alessandro Alessandro Gerardo alessandro.dalessan...@telecomitalia.it 主题: [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 收件人: adr...@olddog.co.uk adr...@olddog.co.uk, m...@ietf.org m...@ietf.org, ietf@ietf.org ietf@ietf.org 日期: 2011年10月5日,周三,下午5:38 Dear all, I do not support. Basically I think it is superfluous dedicate an RFC to state it is better having one standard instead of two ones or many... for sure the lower are the variants the better is for the industry (one is the ideal). When two or more standards or de-facto standards exist it is because the problem they solve is not exactly the same, the way they solve the problem is optimized for different environments/boundary conditions (more efficient, more effective, etc). Therefore a single solution does not necessarily meet the different market requirements. It is fundamental to enter into the problem's details before making consideration about the best way to proceed (one solution, two solutions, multiple solutions) whilst the document clearly declares it does not want to make any technical evaluations. After more than three years of debates within the IETF and major unresolved technical concerns risen from some transport operators, the existence of this draft is by itself the sure sign that MPLS-TP OAM is a case where a single solution has not be found to meet all the different market requirements. Otherwise, why are we still discussing about it? Therefore we must be realistic and the
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
R: [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
Dear all, I do not support. Basically I think it is superfluous dedicate an RFC to state it is better having one standard instead of two ones or many... for sure the lower are the variants the better is for the industry (one is the ideal). When two or more standards or de-facto standards exist it is because the problem they solve is not exactly the same, the way they solve the problem is optimized for different environments/boundary conditions (more efficient, more effective, etc). Therefore a single solution does not necessarily meet the different market requirements. It is fundamental to enter into the problem's details before making consideration about the best way to proceed (one solution, two solutions, multiple solutions) whilst the document clearly declares it does not want to make any technical evaluations. After more than three years of debates within the IETF and major unresolved technical concerns risen from some transport operators, the existence of this draft is by itself the sure sign that MPLS-TP OAM is a case where a single solution has not be found to meet all the different market requirements. Otherwise, why are we still discussing about it? Therefore we must be realistic and the lessons learned from the past should guide our decisions: if a solution cannot be found for satisfying all the requirements it is better to have two standards and let the market decide how to exploit them. Are we really sure the cost(many) / benefit (none) analysis done in section 7.5 is realistic? Best regards, Alessandro -- Telecom Italia Alessandro D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -Messaggio originale- Da: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] Per conto di Adrian Farrel Inviato: lunedì 26 settembre 2011 23:58 A: m...@ietf.org Oggetto: [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,
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
Alessandro, Stewart and all, I concur with Stewart: please write a draft detailing your major technical concerns. I'd like to add a quote from Malcolm's presentation at the IETF meeting in Prague: Differences between the solution approved by the IETF and its ITU-T sponsored alternatives - Sasha are close to invisible at the level of the requirements in RFC5860. Just to remind you that RFC 5680 is the MPLS-TP OAM requirements document. Malcolm has also said: Many of the issues only become apparent when the protocol and equipment behavior isexplored but, AFAIK, these issues have never been explicitly brought for the consideration. My 2c, Sasha -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, October 05, 2011 12:24 PM To: D'Alessandro Alessandro Gerardo Cc: 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 On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: major unresolved technical concerns Alessandro Please can I suggest that you write an internet draft detailing these major unresolved technical concerns so that we can all understand them. Such a draft needs to be technical, and describe the actions that the network operator is unable to perform, or the fault cases that they are unable to diagnose using the OAM defined in the IETF RFCs, or late stage WG drafts. Alternatively if you are referring to a bug in the MPLS-TP OAM protocols, you need to tell the community what it is. I believe that this request has been made a number of times, in various forums, and, as far as I know, no document has yet been produced. An argument of the form you must standardize what I want will not fly. What is needed is a very clear technical definition of the issue(s). When we have the major unresolved technical concerns on the table, we will be in a position to determine the best disposition of those issues. Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
回复： [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
Dear all, So many multiple solution cases just show the way that the world and technology works. Killing a solution roughly brings more damage to the industry. Section 3.6 discusses the elements of the choice of solutions. Current application and deployment should be considered. In China Mobile, more than 330,000 PTN box are/will based on G.8113.1. TDM PW gives a good example. G.8113.1 based OAM is relative simple and mature and widely deployed and should be the standard. Best regards, Han Li --- 11年10月5日，周三, D'Alessandro Alessandro Gerardo alessandro.dalessan...@telecomitalia.it 写道： 发件人: D'Alessandro Alessandro Gerardo alessandro.dalessan...@telecomitalia.it 主题: [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 收件人: adr...@olddog.co.uk adr...@olddog.co.uk, m...@ietf.org m...@ietf.org, ietf@ietf.org ietf@ietf.org 日期: 2011年10月5日,周三,下午5:38 Dear all, I do not support. Basically I think it is superfluous dedicate an RFC to state it is better having one standard instead of two ones or many... for sure the lower are the variants the better is for the industry (one is the ideal). When two or more standards or de-facto standards exist it is because the problem they solve is not exactly the same, the way they solve the problem is optimized for different environments/boundary conditions (more efficient, more effective, etc). Therefore a single solution does not necessarily meet the different market requirements. It is fundamental to enter into the problem's details before making consideration about the best way to proceed (one solution, two solutions, multiple solutions) whilst the document clearly declares it does not want to make any technical evaluations. After more than three years of debates within the IETF and major unresolved technical concerns risen from some transport operators, the existence of this draft is by itself the sure sign that MPLS-TP OAM is a case where a single solution has not be found to meet all the different market requirements. Otherwise, why are we still discussing about it? Therefore we must be realistic and the lessons learned from the past should guide our decisions: if a solution cannot be found for satisfying all the requirements it is better to have two standards and let the market decide how to exploit them. Are we really sure the cost(many) / benefit (none) analysis done in section 7.5 is realistic? Best regards, Alessandro -- Telecom Italia Alessandro D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -Messaggio originale- Da: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] Per conto di Adrian Farrel Inviato: lunedì 26 settembre 2011 23:58 A: m...@ietf.org Oggetto: [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
R: [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
Dear Stewart, Many thanks for your answer that anyway I do not believe addresses the root concern I have on the proposed draft. I would avoid bringing technical discussions into this thread because it is a declared intent of the draft in the object to NOT touch such aspects. I'm therefore going to answer you on a different thread. Best regards, Alessandro -- Telecom Italia Alessandro D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -Messaggio originale- Da: Stewart Bryant [mailto:stbry...@cisco.com] Inviato: mercoledì 5 ottobre 2011 12:24 A: D'Alessandro Alessandro Gerardo Cc: adr...@olddog.co.uk; m...@ietf.org; ietf@ietf.org Oggetto: 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 On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: major unresolved technical concerns Alessandro Please can I suggest that you write an internet draft detailing these major unresolved technical concerns so that we can all understand them. Such a draft needs to be technical, and describe the actions that the network operator is unable to perform, or the fault cases that they are unable to diagnose using the OAM defined in the IETF RFCs, or late stage WG drafts. Alternatively if you are referring to a bug in the MPLS-TP OAM protocols, you need to tell the community what it is. I believe that this request has been made a number of times, in various forums, and, as far as I know, no document has yet been produced. An argument of the form you must standardize what I want will not fly. What is needed is a very clear technical definition of the issue(s). When we have the major unresolved technical concerns on the table, we will be in a position to determine the best disposition of those issues. Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. ___ 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
Hi, Here's the review I promised earlier. I still think it would be best to not publish the draft for the reasons I mentioned earlier. In case the IETF wants to move this document forward I think at least a number of things need to change: a) The document makes a number of assertions that I think are not correct. E.g. it states that the solutions must be implementable in software. I cannot recall that there was any assertion about whether some, all or none of the things that the requirements documents prescribe should be build in HW or SW. A vendor needs to build equipment that fulfills the requirements, the standard needs to specify mechanisms that fulfill the requirements. If a vendor can build it in SW fine, if it has to be done in HW fine. But the main point is that everything needs to fulfill the specs which fulfill the requirements. b) The complexity sausage needs to go. The section does not help the goal of the document or the relevant parts are duplicated later in the text. c) Some text passages are overly dramatic and could use a little down-toning (e.g. (something that would inevitably drive all customers away!)). Others use absolute figures for speculative things (like increases cost by a factor of two etc.). Yet others are not very polite to certain vendors like forces all serious router vendors to implement both protocols. I am not sure the IETF wants to call router vendors to be not serious if they only implement either OSPF or ISIS. The basic message is the text needs a serious cleanup of language. d) Section 6 needs to go. I do not think that these coexistence models are agreed by the wider IETF community and I don't think they help the message of the document. e) The document should provide more references for some of the statements that caused dispute on the list. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Rolf Winter Sent: Dienstag, 4. Oktober 2011 11:17 To: Brian E Carpenter; 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 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 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Freitag, 30. September 2011 21:48 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
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
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
I concur with Dave's comment and support publication of the draft. Dave On Oct 5, 2011, at 7:06 PM, David Allan I david.i.al...@ericsson.com wrote: 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
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
I do not support this draft. a) Its SONET and SDH section is wrong. (Please refer to H. van Helvoort's, A. Reid's, M. Betts's comments.) b) It doesn't really add anything to RFC 1958. (Please refer to R. Winter's comments.) In RFC1958: 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. We didn't choose the elsewhere designs (ETH, T-MPLS; please check deployment numbers in other emails on this subject) on the grounds of backwards compatibility, but didn't choose the internet context design either, once the chosen IETF designs won't be backwards compatible with existing ones. (Please refer to the Jul2011 discussion regarding cc-cv-rdi draft) 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. (Please refer f.i. to the Jul2011 discussion regarding cc-cv-rdi draft) d) I do agree with the supporters of this draft on we are going in circles again. There are enough people supporting both solutions. Those supporting the ITU-T approach don't preclude the IETF's, although not subscribing it. Those supporting the IETF's do preclude ITU-T's. I don't understand the goal and time waste. As a final client, i don't understand why people want to preclude me of a valuable option. 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 (OAM). This enables fault management and performance monitoring to the level needed in a
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 (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
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, 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 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Freitag, 30. September 2011 21:48 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
- Original Message - From: Scott O Bradner s...@sobco.com To: IETF Discussion ietf@ietf.org Sent: Thursday, September 29, 2011 6:30 PM I'm having a hard time understanding just what this document is trying to do Scott Provide another instalment in the long running and yet-to-be resolved disagreement as to how additional OAM should be added to MPLS to bring it up to the level required in a Transport Network by network operators. Look at the archives of this list for a post by Russ 2Mar2011 for an earlier instalment. The MPLS-TP list has a thread 'Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02]' in Jan 2011 which precedes that. The same list has ' MPLS WG slides from CMCC' in November 2010 which says Actually, China Mobile has introduced 38,000 PTN equipments based on pre-standard G.8114 in 2009. China Mobile will introduce more than 110,000 PTN equipments based on draft-bhh-MPLS-TP-OAM-Y1731 in 2010. (draft-bhh being the proposal for OAM that the IETF did not adopt for Packet Transport Networks). and a thread at the same time 'How can ITU-T experts contribute to the work on MPLS-TP?' which I think the crux of the problem. IETF has a way of working, and IETF claims technical control over MPLS code points, but those supporting draft-bhh have failed to achieve agreement, in the way that the IETF defines agreement (which is not the way in which other SDOs define agreement), that theirs should be the way forward to add the necessary functionality to MPLS OAM. So we have two technical solutions; perhaps they will coexist, perhaps the marketplace will decide etc, as this I-D says. It is not a happy state of affairs, and there is no technical solution. Quite how this will play out is hard to see but in a few years time, I fear we will look back and say 'if only'. Tom Petch I understand from the title that it is supposed to be telling the reader why a single OAM solution is a good idea for MPLS-TP if that is the case I'm not all that sure what the purpose of sections 4 and 5 are for - they seem to be exploring land outside the reservation - how about just addressing the topic in the title? Scott ___ 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
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, Section 1.1 contains the following text: An analysis of the technical options for OAM solutions was carried out by a design team (the MEAD team) consisting of experts from both the ITU-T and the IETF. The team reached an agreement on the principles of the design and the direction for the development of an MPLS-TP OAM toolset. I was a member of the MEAD team, I do not support this conclusion. A report was subsequently submitted to the IETF MPLS Working Group at the Stockholm IETF meeting in July 2009. Please provide a reference to the report. I would like to read it, and see what my conclusion was. The guidelines drawn up by the design team have played an important role in the creation of a coherent MPLS-TP OAM solution. The MEAD team was disbanded before the guidelines were finished and agreed within the team. Regards, Huub. ___ 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, 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. Regards, Huub (member of the JWT). ___ 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, 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
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
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
At 12:42 26-09-2011, 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 Given that previous discussions about MPLS-TP raised a few controversies, I wondered what this document was about and why it wasn't a working group document. The document mentions that it is intended to explain why it would be unwise to standardize multiple solutions for MPLS-TP OAM. And the objective is to determine whether there is IETF Consensus for that. According the shepherd write-up, this document is an analysis of wider IETF policy and process. Could the document shepherd please clarify what he means by that? In Section 4.3: The application layer of the Internet is, however, predicated on a business model that allows for free or shared software (such as in open source developments), and is only possible with the existence of a royalty free codec. I cannot parse the above sentence. There were some arguments [1] from an IETF participant: The IETF should *NOT* document any comment on any multiple standards developed by other SDOs The IETF should refrain from documenting things that might offend other SDOs I could not find anything offensive. For example, Section 5.3 mentions that: Sometimes, customers were obliged to obtain an additional device from their service providers in order to roam when travelling abroad (for example, when travelling from Europe to the U.S). There is a cost when the user has to work around such issues. The IETF already has a policy about inter-SDO impact. Quoting Section 2.2 of RFC 4041: [The IETF] must allow for other moral frameworks and fully respect other people's right to subscribe to other belief systems. Such people are, however, wrong and doomed to spend eternity in a dark corner with only dial-up access. So it has been written. Regards, -sm 1. http://www.ietf.org/mail-archive/web/ietf/current/msg69674.html ___ 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
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. 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. --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
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) The IETF should refrain from documenting things that might offend other SDOs concerning standards issues in which IETF was or is not involved. Since when does offending other SDOs become a concern of any other SDO? Along these lines, let us take the flip-side of that example you give and ask ourselves why the ITU-T's comments on MPLS do not offend IETF folks (or other SDOs for that matter) and why there was not a concern of offending when those were made? --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
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 09/29/2011 09:18 AM, Thomas Nadeau wrote: 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) I would say that having knowledge of a topic is a requirement, but that *expert* knowledge of a topic is not a requirement. Just look at the IETF mailing lists. There are plenty of people with something to say who do not to have expert knowledge of a topic. Almost certainly of us at one time or another. Sometimes new ideas come from looking at a problem without the preconceptions that come with being an expert. Sometimes experts really do know better. This is why we have discussions to build consensus as to which ideas should be kept or discarded. Both experts and nonexperts can have valuable contributions and improve each others understanding. -Andrew Not an expert on standards or even SONET/SDH, CDMA/GSM The IETF should refrain from documenting things that might offend other SDOs concerning standards issues in which IETF was or is not involved. Since when does offending other SDOs become a concern of any other SDO? Along these lines, let us take the flip-side of that example you give and ask ourselves why the ITU-T's comments on MPLS do not offend IETF folks (or other SDOs for that matter) and why there was not a concern of offending when those were made? --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
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
