RE: FW: LastCall:draft-betts-itu-oam-ach-code-point-03.txt(Allocationofan Associated Channel Code Point for Use byITU-T Ethernetbased OAM) toInformational RFC
We certainly have running code, widely deployed (although my request on the MPLS list as to which manufacturers' boxes were involved never did get answered:-( Hope these help: http://tools.ietf.org/html/draft-fang-mpls-tp-oam-considerations http://www.eantc.com/fileadmin/eantc/downloads/events/2007-2010/CEWC09/EANTC-CEWC2009-WhitePaper-v1_2.pdf Regards, Rui -Original Message- From: t.petch [mailto:daedu...@btconnect.com] Sent: sexta-feira, 23 de Março de 2012 09:58 To: Alia Atlas; Rui Costa Cc: ietf@ietf.org Subject: Re: FW: LastCall:draft-betts-itu-oam-ach-code-point-03.txt(Allocationofan Associated Channel Code Point for Use byITU-T Ethernetbased OAM) toInformational RFC - Original Message - From: Alia Atlas akat...@gmail.com To: Rui Costa rco...@ptinovacao.pt Cc: ietf@ietf.org Sent: Thursday, March 22, 2012 10:07 PM Rui, Perhaps more familiarity with the related history over the last several years would help? I can recommend the MPLS list archives. Otherwise, I find this remarkably disingenuous. This is a case of a second solution that was clearly rejected by the MPLS working group (despite in-person histrionics causing the ADs to have to threaten to close down the WG meeting). Then the solution was taken to the ITU study group - where it could also not get enough traction for their normal process. It is still not approved as a recommendation. tp Alia Were the roles reversed and the second solution be a product of the IETF that the IETF were trying to get more widely approved, would the IETF allocate a code point? I think that it would. We certainly have running code, widely deployed (although my request on the MPLS list as to which manufacturers' boxes were involved never did get answered:-(. We have a rough consensus; not unanimity, and not enough of a consensus to satisfy the processes of the ITU-T but I think enough to satisfy the consensus-judgers of the IETF (as ever, we do not vote, a majority of e-mails for one point of view may be discounted, it is the quality of the views expressed that matters as much or more). So applying the standards to which we work, I think this is another reason why we should approve this I-D. Tom Petch /tp To imply that the IETF should simply trust the allocated ACH code point to not be abused both seems optimistic and sets a dreadful precedent. Making an allocation available for an approved recommendation version is a tolerable way of reducing the deliberate use of an experimental value. Handing the keys over for any conceivable use, or even just the uses in the OAM RFC that have been adequately met by IETF WG-consensus based technology, does not seem appropriate. Alia On Thu, Mar 22, 2012 at 10:42 AM, Rui Costa rco...@ptinovacao.pt wrote: I fail to understand the issue under discussion. Can't imagine IEEE denying to grant Ethertype 0x86DD. If, however, from absurd that had happened, would the world stop or would we take the same information from the IP header version field? Regards, Rui -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Alia Atlas Sent: quarta-feira, 21 de Março de 2012 15:30 To: D'Alessandro Alessandro Gerardo Cc: ietf@ietf.org Subject: Re: הנדון: RE: Last Call:draft-betts-itu-oam-ach-code-point-03.txt(Allocationof an Associated Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational RFC Considering that the need for this code point is a result of the ITU not fully complying with the IETF agreement, I cannot agree that we should simply allocate a code point for whatever the ITU wants to do in the future. It seems the best of the options to allocate a code point (much better than squatting) - but tie it to a stable reference. If the ITU can't provide a stable reference, then perhaps an RFC is the best way. There are lots of folks with opinions on the best procedure, but I certainly don't support the idea of not restricting the usage to what is clearly defined. Alia
FW: Last Call:draft-betts-itu-oam-ach-code-point-03.txt(Allocationof an Associated Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational RFC
I fail to understand the issue under discussion. Can't imagine IEEE denying to grant Ethertype 0x86DD. If, however, from absurd that had happened, would the world stop or would we take the same information from the IP header version field? Regards, Rui -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Alia Atlas Sent: quarta-feira, 21 de Março de 2012 15:30 To: D'Alessandro Alessandro Gerardo Cc: ietf@ietf.org Subject: Re: הנדון: RE: Last Call:draft-betts-itu-oam-ach-code-point-03.txt(Allocationof an Associated Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational RFC Considering that the need for this code point is a result of the ITU not fully complying with the IETF agreement, I cannot agree that we should simply allocate a code point for whatever the ITU wants to do in the future. It seems the best of the options to allocate a code point (much better than squatting) - but tie it to a stable reference. If the ITU can't provide a stable reference, then perhaps an RFC is the best way. There are lots of folks with opinions on the best procedure, but I certainly don't support the idea of not restricting the usage to what is clearly defined. Alia -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: quarta-feira, 21 de Março de 2012 07:42 To: huubatw...@gmail.com; ietf@ietf.org Subject: RE: Last Call: draft-betts-itu-oam-ach-code-point-03.txt (Allocationof an Associated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC Hello, I still expect the author of draft-betts to answer my question... Maybe you could clarify how the text in your draft can be improved to protect the use of the code point from future extensions beyond the purpose of the code point allocation? I am a bit disappointed to see that the author simply does not respond to the questions and proposed modifications he got on the list. If we want to productively move forward, it would be good to have the author responding to the questions and proposals. Best regards, Nurit - Original Message - From: Sprecher, Nurit (NSN - IL/Hod HaSharon) nurit.sprec...@nsn.com To: Andrew G. Malis agma...@gmail.com; ext Ross Callon rcal...@juniper.net Cc: ietf@ietf.org Sent: Tuesday, March 13, 2012 8:09 PM Subject: הנדון: RE: Last Call:draft-betts-itu-oam-ach-code-point-03.txt(Allocationof an Associated Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational RFC Ross, i am afraid that you missed the point. There will not be a final version since as written in draft-betts, all ITU recommendations are subject to revisions, and the code point will also be used for future revisions of the document. New messages/protocols can be defined in future revisions of the recommendation and they will use the same code point that is allocated for the first version. This is a real issue. Regards, Nurit -הודעה מקורית- מאת: ext Ross Callon נשלח: 13/03/2012, 19:27 אל: Andrew G. Malis; Sprecher, Nurit (NSN - IL/Hod HaSharon) עותק: ietf@ietf.org נושא: RE: Last Call:draft-betts-itu-oam-ach-code-point-03.txt(Allocationof an Associated Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational RFC I agree that the allocation of a code point should be to a specific version of 8113.1, tp Why? I can understand a new code point being required if there is a new and backwards incompatible format for the messages, but if the messages are extended in a forwards compatible manner, adding new TLV for example, or a new format of IF_ID, then why should we burn a new code point? Would you say that we should have a dozen different port numbers for HTTP to reflect its evolution over time? If not, why not? Demanding that the ITU-T come back to us for a new round of negotiation when it is technically unnecessary seems to be placing an unnecessary barrier between the two SDOs. Tom Petch and specifically should be to the final version that is approved by the ITU-T (assuming that a final version of 8113.1 will be approved by the ITU-T). This would imply that draft-betts-itu-oam-ach-code-point should contain a normative reference to the final approved version of 8113.1. Given normal IETF processes, this implies that the final RFC resulting from draft-betts-itu-oam-ach-code-point could be published as soon as the final version of 8113.1 is approved (with the understanding that there will be a small normal delay between approved and published which gives time for coordination). Given that the final version of 8113.1 might need to reference the RFC resulting from draft-betts-itu-oam-ach-code-point, a bit of cooperation might be needed between editorial staff at the ITU and RFC editorial staff, but I don't see why this should be a problem (I am sure that they all have access to email). Ross
RE: Last Call: draft-ietf-mpls-tp-oam-analysis-08.txt (An Overview of the OAM Tool Set for MPLS based Transport Networks) to Informational RFC
Hello, i) I support this proposal. Apart from the text section mentioned below, the different versions of the draft (at least the initial ones) have presented, from the available options and IMHO, Y.1731 as the readiest/closest most to requirements. On the other hand, this section looks to want being a memorandum about decisions regarding OAM, which didn't follow that option. So, it's important not to put ITU-T or MEAD in subject for that. ii) [RFC 6375] augments that set of identifiers to include identifier information in a format used by the ITU-T Is the intended reference [MPLS TP ITU Idents], draft-ietf-mpls-tp-itu-t-identifiers? 6375's related to packet loss and delay measurements, not to identifiers. Regards, Rui -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Huub van Helvoort Sent: quarta-feira, 21 de Março de 2012 22:49 To: ietf@ietf.org Subject: Re: Last Call: draft-ietf-mpls-tp-oam-analysis-08.txt (An Overview of the OAM Tool Set for MPLS based Transport Networks) to Informational RFC IESG, I do *NOT* support this draft unless the following changes are made: The first paragraph of section 8 Acknowledgements has to be removed: It is an attempt to capture history, but lacks accuracy. Removal does not impact the technical information in the draft; the tools have evolved significantly from the strawman tools proposed in Stockholm; some members of the MEAD team (I am one of them) do not consider that an agreement on this proposal was reached. I also request the removal of my name from this acknowledgements section since I do not support this tool set, neither as an individual nor as ITU-T Q10 rapporteur. The latter is implied by mentioning my name in the same sentence as a WG chair and ADs. Regards, Huub. = The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'An Overview of the OAM Tool Set for MPLS based Transport Networks' draft-ietf-mpls-tp-oam-analysis-08.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 2012-03-23. 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 This document provides an overview of the OAM toolset for MPLS based Transport Networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data-plane) which are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels. This overview includes a brief recap of MPLS-TP OAM requirements and functions, and of generic mechanisms created in the MPLS data plane to allow the OAM packets run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group drafts) which are referenced by this document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-analysis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-analysis/ballot / 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
RE: Last Call: draft-betts-itu-oam-ach-code-point-03.txt (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to Informational RFC
Hello, I support the allocation of an ACH codepoint to G.8113.1, not precluding the ITU-T to progress refinements. Ergo, i support this draft and proposal http://www.ietf.org/mail-archive/web/ietf/current/msg72191.html. IMHO, the status quo analysis expressed in both http://www.ietf.org/mail-archive/web/ietf/current/msg72188.html and http://www.ietf.org/mail-archive/web/ietf/current/msg72273.html is accurate. Regards, Rui Original Message From: The IESG iesg-secret...@ietf.org Sent: Wed, 22 Feb 2012 07:12:52 -0800 To: IETF-Announce ietf-annou...@ietf.org Subject: Last Call: draft-betts-itu-oam-ach-code-point-03.txt (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM' draft-betts-itu-oam-ach-code-point-03.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 2012-03-21. 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 This document assigns an Associated Channel Type code point for carrying Ethernet based Operations, Administration, and Management messages in the MPLS Generic Associated Channel (G-ACh). The file can be obtained via http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ 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
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: [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: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard
David, T-MPLS rose from MPLS/IP's OAM blanks. Our main interest on it is the simple/reliable OAM we had in SDH but lost in MPLS/IP. Otherwise, the work in T-MPLS or MPLS-TP would be rather pointless. ITU-T was historically the right place to define such OAM. So, our interest started with ITU-T's work in T-MPLS and not when IETF joined. We value IETF's work, and in 2008, when the IETF rose doubts about future interoperability between T-MPLS and MPLS/IP (and the danger to the internet), even though all T-MPLS Recommendations were approved and the OAM one was ready for approval, a decision was made to listen carefully to MPLS/IP's top experts' input. IETF's unilateral decision to select BFD was IMHO a surprise: being a primary goal in T-MPLS, i'd assume OAM definition was ITU-T's responsibility/expertise or at least a compromise between the 2 SDOs. ITU-T's not just a boilerplate stamper. Hearing that the decision was expressed in mpls-tp-analysis draft was another surprise: among the possible ways, the document showed, IMHO, 1731 as the closest one to requirements. We don't need a requirement to agree on reusing as most as possible MPLS and PW: it's common sense. However, it can't distract us from primary goals. The issue is not code point, which is the trivial part. It is reuse of the majority of the implementation. Again, pretty basic. In other words, the problem is not backwards compatibility, (ergo the danger to the internet problem never really existed) but maintaining particular deployed platforms. If we had to convert cars into planes, we couldn't say to reuse the implementation, we can't add wings: they wouldn't fly. I'm used to FW/HW development and i don't share your cost/simplicity view. (Please check other LC responses on this particular point.) I know field network support and think you'd change your opinion if you had to work on 24h field network support. I agree with you that other opinions exist, counting not only manufacturers but also operators. On the operators that don't agree with you are certainly clients of yours. It's none of my business that you view their opinions as grumblings, but that's far from describing the polls' results in the Feb2011 WG3 and SG15 plenaries, showing a minority sharing your view, and that, although those not subscribing it tolerate its evolution, you don't theirs. Operators and their clients are the ones that, at the end of the day, pay for networks. From the above, it'll be IMHO impossible to understand if these Recommendations don't take into account these grumblers' view, other than the obsession of those insisting to sell swiss knifes to those who just want sharp scalpels. Why don't we call that also not constructive? [R:] IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which. [D:]That is because MPLS-TP is not a new techology, it is an addition to the entire MPLS protocol suite. Yes, i understand your view, David, but i'm sure you and i don't subscribe this one: The creatures outside looked from pig to man, and from man to pig, and from pig to man again; but already it was impossible to say which was which. Hope this helps. My comrade cents, Rui -Original Message- From: David Allan I [mailto:david.i.al...@ericsson.com] Sent: sexta-feira, 8 de Julho de 2011 17:13 To: Rui Costa; Stewart Bryant Cc: erminio.ottone...@libero.it; m...@ietf.org; ietf@ietf.org; IETF-Announce Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Rui: You wrote: Reading something, keeping it on record, without effect in the draft and ignoring comments have IMHO similar outcomes. As author of the draft you are free to do it. These standards have a great impact in our work, so i'm also free to write what i did. Numerous comments did have effect on the draft and those that didn't were either simply not actionable, were rhetorical or not constructive, and a few had to be balanced against comments coming from the MPLS BFD WGs. I would translate ingored or without effect to did not get one'e way. In the standards process it happens. My technical concerns regarding this draft were expressed... ...in the (ITU-T - IETF, Feb/2011) liaison regarding it (LS281, i believe); ...in operators' meetings' that took place during ITU-T's Feb/2011 plenary meeting; I and the WG don't really have access to private grumblings. Lots of other opinions were expressed as well, and they did not all agree with you. Some: CC/CV I don't understand the need for 2 types of packets: a single type allows CC; mismatching identifiers in the same CC packets allow CV. Besides adding complexity, we whether always activate both or potentiate undetected mismerges. OK, lets walk through this. We want CV all the time so that any misconectivity can
RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard
David, Reading something, keeping it on record, without effect in the draft and ignoring comments have IMHO similar outcomes. As author of the draft you are free to do it. These standards have a great impact in our work, so i'm also free to write what i did. Stewart, My technical concerns regarding this draft were expressed... ...in the (ITU-T - IETF, Feb/2011) liaison regarding it (LS281, i believe); ...in operators' meetings' that took place during ITU-T's Feb/2011 plenary meeting; ...in a comparison session that took place during that same ITU-T meeting. Some: CC/CV I don't understand the need for 2 types of packets: a single type allows CC; mismatching identifiers in the same CC packets allow CV. Besides adding complexity, we whether always activate both or potentiate undetected mismerges. (BTW: can't understand how we propose one ACH codepoint to CC, another for CV, [counting other drafts, another for frame loss ...] but don't consider assigning 1 single ACH protocol identifier codepoint as requested by ITU-T) Uni P2P / P2MP I can't see how BFD will support unidir and hence P2MP other than... ...eliminating the session state variable (down, init, up), aiming just the state variables we really need, bringing us to something similar to 1731, eventually with other bits on the wire or... ...using IP to create the reverse way, which we cannot assume per requirements; Will we create a complete different tool for that? (BFD's B=bidirectional) Provisioning list This is an MPLS profile/subset (and i heard) achievable through a particular configuration. So, i expect each draft-ietf-mpls-TP-* to focus on that profile/configuration. However, i keep seeing references f.i. to IP encapsulations unexpected under TP's OAM. I don't thus understand what the aim is: do we expect this in TP, are we talking about MPLS in general?... The TP profile is never quite delimited. Does chapter 4 contain ALL the configurable parameters list agreed to provide in the comparison session? Backwards compatibility This was the main argument risen to ground MPLS-TP OAM on BFD. It's not a better argument than grounding MPLS-TP OAM on 1731 due to its ETH deployment plus coherence with SDH, OTN, as defended by ITU-T. For reasons like the above, however, MPLS-TP BFD won't be backwards compatible with previous BFD (even considering just CC/CV). They don't even share the same codepoint. Simplicity Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is simpler: in each flow, a standard defined nr of constant heartbeat signals (with standard constant or provisioned period - no auto/negotiated -) means OK. A standard defined number of misses means lost Rx connection. An RDI, the only articulation between Rx and Tx flows, meaningful in bidirectional applications, allows each pear to identify Tx problems. This OAM simplicity is the key for reliable fail finger pointing, performance reports and protection. Also to allow scaling, more implementation opportunities/manufacturers, which is valuable for operators. IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which. Regards, Rui -Original Message- From: David Allan I [mailto:david.i.al...@ericsson.com] Sent: quarta-feira, 6 de Julho de 2011 19:25 To: erminio.ottone...@libero.it; Rui Costa; ietf@ietf.org; IETF-Announce Cc: m...@ietf.org Subject: RE: [mpls] R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Hi Erminio: snipped Several service providers regarded this draft as not meeting their transport networks' needs. E This is a true statement: the solution in this draft is useless for many MPLS- TP deployments. The two statements do not necessarily follow. What we established during discussions at the SG15 plenary in February was that the issue some service providers had was that the IETF BFD solution exceeded their requirements in that there was additional functionality they did not see a need for, and that they considered any additional functionality parasitic. However this is a consequence of adapting an existing technology to a new application. I do not see any way around that. And the entire joint project was based on the premise of engineering re-use not greenfield design. That is what it said on the tin up front, and IMO why when the IETF started down this path packet transport transitioned from being a minority sport to mainstream, so it is a bit late to cry foul My 2 cents Dave -Original Message- From: David Allan I [mailto:david.i.al...@ericsson.com] Sent: quarta-feira, 6 de Julho de 2011 18:36 To: erminio.ottone...@libero.it; l...@pi.nu; Rui Costa Cc: m
RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard
IMHO and for the record: ITU-T comments regarding this draft haven't been discussed with ITU-T but were simply ignored. No LS describing these comments' resolution was sent. Several service providers regarded this draft as not meeting their transport networks' needs. [The v03 draft was published in Feb and went to WG LC. The v04 draft addressing WG LC comments was published on the 28th June (same date as the proto write-up). When was the WG LC launched, to verify LC comments resolution?] Regards, Rui -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The IESG Sent: quinta-feira, 30 de Junho de 2011 14:47 To: IETF-Announce Cc: m...@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile' draft-ietf-mpls-tp-cc-cv-rdi-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Continuity Check, Proactive Connectivity Verification and Remote Defect Indication functionalities are required for MPLS-TP OAM. Continuity Check monitors the integrity of the continuity of the label switched path for any loss of continuity defect. Connectivity verification monitors the integrity of the routing of the label switched path between sink and source for any connectivity issues. Remote defect indication enables an End Point to report, to its associated End Point, a fault or defect condition that it detects on a pseudo wire, label switched path or Section. This document specifies methods for proactive continuity check, continuity verification, and remote defect indication for MPLS-TP label switched paths, pseudo wires and Sections using Bidirectional Forwarding Detection. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ No IPR declarations have been submitted directly on this I-D. ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard
Hello Yaakov, 1. [YS] One of the major problems with Y.1731 is the lack of a 100 packet per second rate, forcing the use of 300 packets per second [RC] I don't understand your 1st claim. Would you be so kind as to detail it to me a bit? In Y.1731, 7.1.1 CCM (with ETH-CC information) Transmission [...] * 10ms: (transmission rate is 100 frames/second) [...] Table 9-3 - CCM Period Values [...] Might you be referring to G.8031's 11.2.4 Transmission and acceptance of APS? If so, isn't it true that it isn't Y.1731 that creates this but G.8031 or another standard imposing that to G.8031? Besides... Is it really imposing? I think having seen words like desirable or should there... [Thank you, Francesco] 2. [YS] The other main fault with Y.1731 is its fracturing [...] among so many different OAM message types, [...] If you only need CCMs, yes Y.1731 is easy (but so is any other heartbeat format) [...] Once you want to do CCs, CCs for protection (G.8031/G.8032 require their own), packet loss measurement, and delay measurement, it becomes a nightmare. [RC] And isn't CCM simplicity a worthy characteristic... The main characteristic? In SDH, the CPU gets an alarm from HW. If you could have a simple means, easily implemented in HW to give firmware the same interface, then you wouldn't need burdening uPs with extra assembling/disassembling PDUs, right? Or you would, if that was your preferred modus operandi. You could choose. As for your other concerns: in principle, i wouldn't oppose adding Y.1731 PDUs that could integrate several functions, if those were integrated in Y.1731 philosophy and accepted by other ITU members. However, that was proposed recently and is still under discussion, whereas we have to take a decision now. Thank you for your time. Best Regards, Rui -Original Message- From: Francesco Fondelli [mailto:francesco.fonde...@gmail.com] Sent: quinta-feira, 8 de Outubro de 2009 9:33 To: Yaakov Stein Cc: Rui Costa; ietf@ietf.org; Adrian Farrel Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard On Thu, Oct 8, 2009 at 8:43 AM, Yaakov Stein yaako...@rad.com wrote: Rui, Hi all, While a co-author of the draft proposing re-use of Y.1731 OAM for MPLS-TP, and quite understanding the reasoning behind reusing existing formats, I am puzzled by two of your statements. First, that Y.1731 CCMs would ease more vendor's implementations to converge to the 50ms protection timescale. One of the major problems with Y.1731 is the lack of a 100 packet per second rate, forcing the use of 300 packets per second at high resource cost. hemm --- T-REC-Y.1731-200802 --- 7.1.1 CCM (with ETH-CC information) Transmission When ETH-CC is enabled, a MEP periodically transmits CCM frames as often as the configured transmission period. Transmission period can be one of the following seven values: - 3.33ms: default transmission period for protection switching application (transmission rate of 300 frames/second) - 10ms: (transmission rate is 100 frames/second) ^^ --- Even if I'm not a big fan of it I have to say that 100 pps is foressen by Y.1731 (and even by your ID, http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-03, Section 4.1.1) [cut] Y(J)S Ciao FF -Original Message- From: Yaakov Stein [mailto:yaako...@rad.com] Sent: quinta-feira, 8 de Outubro de 2009 8:43 To: Rui Costa; ietf@ietf.org Cc: Adrian Farrel Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard Rui, While a co-author of the draft proposing re-use of Y.1731 OAM for MPLS-TP, and quite understanding the reasoning behind reusing existing formats, I am puzzled by two of your statements. First, that Y.1731 CCMs would ease more vendor's implementations to converge to the 50ms protection timescale. One of the major problems with Y.1731 is the lack of a 100 packet per second rate, forcing the use of 300 packets per second at high resource cost. I feel that 50 ms protection requirements are the best reason NOT to use Y.1731. Second, that the mechanisms in Y.1731 are sufficiently simple to allow some hardwarization. The other main fault with Y.1731 is its fracturing of the capabilities among so many different OAM message types, rather than realizing that there are really only two OAM types (one way and reflecting), with options for various monitoring or measurement functions. If you only need CCMs, yes Y.1731 is easy (but so is any other heartbeat format). Once you want to do CCs, CCs for protection (G.8031/G.8032 require their own), packet loss measurement, and delay measurement, it becomes a nightmare. Y(J)S -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf
RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard
SDH and EoSDH networks are widely used by Portugal Telecom Comunicacoes (PTC) and TMN (respectively the incumbent operator in Portugal and PT group's mobile operator), as well as foreign PT's clients (Brazilian Vivo, for instance). These operators are used to both SDH and Ethernet's OAM paradigm. We ask you therefore to consider that MPLS-TP OAM protocols MUST allow equivalent OAM mechanisms. Being more precise, we would like to use the same protocol messages, to give/have the same touchfeel we had in SDH and for less time in ETH. In SDH... -it allows you at each end to check you have signal reception and notify the other end when you don't (RDI) -it does so at different levels (in SDH you can have it both for each VC and for the STM) -it has a means by which to exchange an APS protocol In ETH... -we've been using Y.1731 in EoSDH systems; it was the ITU standard developed for this purpose and was thought in the same principles stated for SDH; the most logical evolution would hence be to use the same PDUs and mechanisms as faithfully as possible with an adequate MPLS-TP encapsulation -MEF defined performance monitoring functions for frame loss measurement [FL], delay measurement, delay variation measurement, which are also addressed in Y.1731 The main reason to use the same PDUs as in Y.1731 is probably the same i guess and respect in RFC5654 2nd general requirements: economy. We can't though forget this requirement list will have impact on ITU standards and that, although much of the work in MPLS-TP is IETF's merit and sweat, probably no one would need it if ITU didn't start T-MPLS (whose interoperability problems with MPLS/IP were afterwards pointed out by IETF and originated all the work we can see now). I would also like to point out that the mechanisms in Y.1731 are sufficiently simple to allow some hardwarization, which would ease more vendor's implementations to converge to the 50ms protection timescale, allowing a way to do this in a cheaper, more scalable and miniaturized way. Thank You for your time. Best Regards, Rui Costa ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
