RE: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC
All, I have read this draft and support the publication as an informational RFC. I believe the document is needed since it explains why it is not beneficial to standardize two solutions for the same purpose. The document also makes clear some of the aspects I was not aware of. It is obvious that two solutions would cause a lot of unnecessary effort and costs. There are many examples which show that competing standards are contra-productive for the goals of each party. I fully agree with one of the statements on this list. I think it would be irresponsible of the IETF not to document this situation. Mehmet -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of ext The IESG Sent: Monday, September 26, 2011 9:43 PM To: IETF-Announce Subject: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational 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-consideration s/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-consideration s/ 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
RE: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC
All, I read this draft and support the publication as an informational RFC. I believe the document is needed since it explains why it is not beneficial to standardize two solutions for the same purpose. The document also makes clear some of the aspects I was not aware of. It is obvious that two solutions would cause a lot of unnecessary effort and costs. There are many examples which show that competing standards are contra-productive for the goals of each party. I fully agree with one of the statements I read on this list. I think it would be irresponsible of the IETF not to document this situation. Mehmet -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of ext The IESG Sent: Monday, September 26, 2011 9:43 PM To: IETF-Announce Subject: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational 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-consideration s/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-consideration s/ 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
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC
I oppose publication of this I-D in its present form. The idea of having an I-D that says two OAM solutions will cost is fine, but there are too many technical errors, especially in sections 4 and 5 (better as Brian suggested as appendices), for it to go forward as it stands. Huub, Malcolm and Andy have pointed out the errors in SONET/SDH, I would take issue with OSPF/ISIS and IPv4/IPv6. The errors aren't gross, but they add up to too many. The sponsoring AD has given his reasons why this is an individual submission but I think that the consequence is that the document quality is too low to be published. It needs the review of a wider body of expertise, the routing area perhaps, before it is published. Tom Petch - Original Message - From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Sent: Monday, September 26, 2011 9:42 PM Subject: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational 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 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
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC
Tom, I don't think there is any objections to improving the document, the most straight-forward way of doing this is the time-honored IETF method supply the text! /Loa On 2011-10-05 10:01, t.petch wrote: I oppose publication of this I-D in its present form. The idea of having an I-D that says two OAM solutions will cost is fine, but there are too many technical errors, especially in sections 4 and 5 (better as Brian suggested as appendices), for it to go forward as it stands. Huub, Malcolm and Andy have pointed out the errors in SONET/SDH, I would take issue with OSPF/ISIS and IPv4/IPv6. The errors aren't gross, but they add up to too many. The sponsoring AD has given his reasons why this is an individual submission but I think that the consequence is that the document quality is too low to be published. It needs the review of a wider body of expertise, the routing area perhaps, before it is published. Tom Petch - Original Message - From: The IESGiesg-secret...@ietf.org To: IETF-Announceietf-annou...@ietf.org Sent: Monday, September 26, 2011 9:42 PM Subject: Last Call:draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational 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 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 -- 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 (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC
Tom I would take issue with OSPF/ISIS and IPv4/IPv6. Please can you expand a little on this. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC
- Original Message - From: Loa Andersson l...@pi.nu To: t.petch daedu...@btconnect.com Cc: ietf@ietf.org Sent: Wednesday, October 05, 2011 1:46 PM Subject: Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC Tom, I don't think there is any objections to improving the document, the most straight-forward way of doing this is the time-honored IETF method supply the text! Which I think belongs in a Working Group with a chair or two and an AD or two, with the relevant expertise in the members, perhaps rtgwg. In such a setting, I might comment that with OSPF and ISIS, the second half of the last paragraph is wrong. They are an example of islands, as described in s.6, but they are required to interwork, in a manner of speaking and do so via BGP, that is we have OSPF-BGP interworking and ISIS-BGP interworking, neither of which are specified outside proprietary solutions, but both of which need to work for the Internet work. Which is a cost of having two solutions. Tom Petch /Loa On 2011-10-05 10:01, t.petch wrote: I oppose publication of this I-D in its present form. The idea of having an I-D that says two OAM solutions will cost is fine, but there are too many technical errors, especially in sections 4 and 5 (better as Brian suggested as appendices), for it to go forward as it stands. Huub, Malcolm and Andy have pointed out the errors in SONET/SDH, I would take issue with OSPF/ISIS and IPv4/IPv6. The errors aren't gross, but they add up to too many. The sponsoring AD has given his reasons why this is an individual submission but I think that the consequence is that the document quality is too low to be published. It needs the review of a wider body of expertise, the routing area perhaps, before it is published. Tom Petch - Original Message - From: The IESGiesg-secret...@ietf.org To: IETF-Announceietf-annou...@ietf.org Sent: Monday, September 26, 2011 9:42 PM Subject: Last Call:draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational 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 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 -- 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(TheReasons for Selecting a Single Solution for MPLS-TP OAM)toInformational RFC
Original Message - From: Stewart Bryant stbry...@cisco.com To: ietf@ietf.org Sent: Wednesday, October 05, 2011 2:01 PM Tom I would take issue with OSPF/ISIS and IPv4/IPv6. Stewart See my reply to Loa for the first. For IPv4/IPv6, we are not talking about two solutions which are concurrent in any sense of the word. When the limitations of IPv4 started to loom on the horizon, work was started on a replacement, and there were several candidates, of which - thankfully - one was chosen. The issue that was not given enough attention was how to migrate the world at large from IPv4 to IPv6. As has been clearly described on the MPLS-TP list, interworking is impossible, the Characteristic Information is too dissimilar, and with interworking being impossible, migration is naturally difficult. So it is an interesting problem, and the coexistence models of s.6 of this I-D are relevant, but it is a poor fit for having two rival solutions being developed concurrently for the same problem. I use video recorders, and latterly the DVD replacement, as poster children for this issue - most people can relate to these examples without needing an in-depth knowledge of A-law or some such:-) Tom Petch Please can you expand a little on this. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
