Re: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt
Hi Russ, Thanks for your comments, very good points. Sorry for the delay in replying, I was out of office. The following is my proposed text for replacing the current first paragraph of section 1.2. Traditional transport technologies include SONET/SDH, TDM, and ATM. There is a transition away from these transport technologies to new packet technologies. In addition to the ever increasing demand for bandwidth, the packet technologies offer these key advantages: Bandwidth efficiency: Transport technologies supports fixed Bandwidth only, no packet statistical multiplexing, bandwidth is reserved in transport whether used or not by clients. Packet technologies support statistical multiplexing, this is the most important motivation for the transition from traditional transport technologies to packet technologies. The proliferation of new distributed applications which communicate with servers over the network in a bursty fashion has been driving the adoption of packet transport techniques, since multiplexing of bursty sources is far more efficient over traditional circuit-based TDM technologies. Flexible data rate connections: Traditional transport connection granularity is limited to the rigid PDH or SONET hierarchy (e.g., DS1, DS3, OC3, OC12, etc.). Packet technologies support flexible data rate connections. The support of finer data rate granularity is important for today¹s wireline and wireless services and applications. QoS support: While traditional transport, such as TDM transport has very limited QoS support, packet transport can provide needed QoS treatment for IPTV, Voice and Video over IP applications. The root cause for transport moving to packet transport is the shift of application from TDM to packet. For example, Voice TDM to VoIP; Video to Video over IP; TDM access lines to Ethernet; TDM VPNs to IP VPNs and Ethernet VPNs. In addition, network convergence and technology refreshes demand for common and flexible infrastructure that provides multiple services. Thanks, Luyuan -Original Message- From: Russ Housley hous...@vigilsec.com Date: Saturday, March 23, 2013 3:16 PM To: ietf@ietf.org ietf@ietf.org Cc: m...@ietf.org m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt I wonder if the direction of Section 1.2 can be revised to make it more of an engineering document. It currently says: In recent years, the urgency for moving from traditional transport technologies, such as SONET/SDH, TDM, and ATM, to new packet technologies has been rising. This is largely due to the fast growing demand for bandwidth, which has been fueled by the following factors: ... Please consider an approach that describes the the reasons behind the transition from the network operator and network user perspectives: Traditional transport technologies include SONET/SDH, TDM, and ATM. There is a transition away from these transport technologies to new packet technologies. In addition to the ever increasing demand for bandwidth, the packet technologies offer these advantages: ... The fact that IP networks are being used for new applications and that the legacy devices are getting old does not motivate the transition to packet technologies. The advantages that packet technologies offer for these new applications is the thing that needs to be highlighted here, even if it is just a list of bullets. It seems like the only sentence that addresses this point in Section 1.2 is: It streamlines the operation, reduces the overall complexity, and improves end-to-end convergence. Thanks, Russ On Jan 28, 2013, at 3:01 PM, The IESG wrote: The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS-TP Applicability; Use Cases and Design' draft-ietf-mpls-tp-use-cases-and-design-06.txt as 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 2013-02-11. 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 applicability, use case studies and network design considerations for the Multiprotocol Label Switching Transport Profile (MPLS-TP). The use cases include Metro Ethernet access and aggregation transport, Mobile backhaul, and packet optical transport. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-use-cases-and-design/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-use-cases-and-design/b allot/ No IPR declarations have been submitted directly on this I-D. ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls default[4
RE: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt
Hi Luyuan, You wrote (in part): ..since multiplexing of bursty sources is far more efficient over traditional circuit-based TDM technologies. Which is not true and probably not what you meant. A better formulation might be since packet multiplexing of traffic from bursty sources provides more efficient use of bandwidth than traditional circuit-based TDM technologies. To be honest however, I'd cut the traditional and use only TDM (since some 'circuit' based technologies also offer packet multiplexing) so I'd reduce it to: A better formulation might be since packet multiplexing of traffic from bursty sources provides more efficient use of bandwidth than TDM technologies. cheers, pd -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of ext Luyuan Fang (lufang) Sent: Monday, April 01, 2013 9:05 PM To: Russ Housley; ietf@ietf.org Cc: m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt Hi Russ, Thanks for your comments, very good points. Sorry for the delay in replying, I was out of office. The following is my proposed text for replacing the current first paragraph of section 1.2. Traditional transport technologies include SONET/SDH, TDM, and ATM. There is a transition away from these transport technologies to new packet technologies. In addition to the ever increasing demand for bandwidth, the packet technologies offer these key advantages: Bandwidth efficiency: Transport technologies supports fixed Bandwidth only, no packet statistical multiplexing, bandwidth is reserved in transport whether used or not by clients. Packet technologies support statistical multiplexing, this is the most important motivation for the transition from traditional transport technologies to packet technologies. The proliferation of new distributed applications which communicate with servers over the network in a bursty fashion has been driving the adoption of packet transport techniques, since multiplexing of bursty sources is far more efficient over traditional circuit-based TDM technologies. Flexible data rate connections: Traditional transport connection granularity is limited to the rigid PDH or SONET hierarchy (e.g., DS1, DS3, OC3, OC12, etc.). Packet technologies support flexible data rate connections. The support of finer data rate granularity is important for today¹s wireline and wireless services and applications. QoS support: While traditional transport, such as TDM transport has very limited QoS support, packet transport can provide needed QoS treatment for IPTV, Voice and Video over IP applications. The root cause for transport moving to packet transport is the shift of application from TDM to packet. For example, Voice TDM to VoIP; Video to Video over IP; TDM access lines to Ethernet; TDM VPNs to IP VPNs and Ethernet VPNs. In addition, network convergence and technology refreshes demand for common and flexible infrastructure that provides multiple services. Thanks, Luyuan -Original Message- From: Russ Housley hous...@vigilsec.com Date: Saturday, March 23, 2013 3:16 PM To: ietf@ietf.org ietf@ietf.org Cc: m...@ietf.org m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt I wonder if the direction of Section 1.2 can be revised to make it more of an engineering document. It currently says: In recent years, the urgency for moving from traditional transport technologies, such as SONET/SDH, TDM, and ATM, to new packet technologies has been rising. This is largely due to the fast growing demand for bandwidth, which has been fueled by the following factors: ... Please consider an approach that describes the the reasons behind the transition from the network operator and network user perspectives: Traditional transport technologies include SONET/SDH, TDM, and ATM. There is a transition away from these transport technologies to new packet technologies. In addition to the ever increasing demand for bandwidth, the packet technologies offer these advantages: ... The fact that IP networks are being used for new applications and that the legacy devices are getting old does not motivate the transition to packet technologies. The advantages that packet technologies offer for these new applications is the thing that needs to be highlighted here, even if it is just a list of bullets. It seems like the only sentence that addresses this point in Section 1.2 is: It streamlines the operation, reduces the overall complexity, and improves end-to-end convergence. Thanks, Russ On Jan 28, 2013, at 3:01 PM, The IESG wrote: The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS-TP Applicability; Use Cases and Design' draft-ietf-mpls-tp-use-cases-and-design-06.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits
Re: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt
Works for me. Thanks, Paul. Luyuan -Original Message- From: Doolan, Paul (NSN - US/Irving) paul.doo...@nsn.com Date: Tuesday, April 2, 2013 7:58 AM To: Luyuan Fang luf...@cisco.com, Russ Housley hous...@vigilsec.com, ietf@ietf.org ietf@ietf.org Cc: m...@ietf.org m...@ietf.org Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt Hi Luyuan, You wrote (in part): ..since multiplexing of bursty sources is far more efficient over traditional circuit-based TDM technologies. Which is not true and probably not what you meant. A better formulation might be since packet multiplexing of traffic from bursty sources provides more efficient use of bandwidth than traditional circuit-based TDM technologies. To be honest however, I'd cut the traditional and use only TDM (since some 'circuit' based technologies also offer packet multiplexing) so I'd reduce it to: A better formulation might be since packet multiplexing of traffic from bursty sources provides more efficient use of bandwidth than TDM technologies. cheers, pd -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of ext Luyuan Fang (lufang) Sent: Monday, April 01, 2013 9:05 PM To: Russ Housley; ietf@ietf.org Cc: m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt Hi Russ, Thanks for your comments, very good points. Sorry for the delay in replying, I was out of office. The following is my proposed text for replacing the current first paragraph of section 1.2. Traditional transport technologies include SONET/SDH, TDM, and ATM. There is a transition away from these transport technologies to new packet technologies. In addition to the ever increasing demand for bandwidth, the packet technologies offer these key advantages: Bandwidth efficiency: Transport technologies supports fixed Bandwidth only, no packet statistical multiplexing, bandwidth is reserved in transport whether used or not by clients. Packet technologies support statistical multiplexing, this is the most important motivation for the transition from traditional transport technologies to packet technologies. The proliferation of new distributed applications which communicate with servers over the network in a bursty fashion has been driving the adoption of packet transport techniques, since multiplexing of bursty sources is far more efficient over traditional circuit-based TDM technologies. Flexible data rate connections: Traditional transport connection granularity is limited to the rigid PDH or SONET hierarchy (e.g., DS1, DS3, OC3, OC12, etc.). Packet technologies support flexible data rate connections. The support of finer data rate granularity is important for today¹s wireline and wireless services and applications. QoS support: While traditional transport, such as TDM transport has very limited QoS support, packet transport can provide needed QoS treatment for IPTV, Voice and Video over IP applications. The root cause for transport moving to packet transport is the shift of application from TDM to packet. For example, Voice TDM to VoIP; Video to Video over IP; TDM access lines to Ethernet; TDM VPNs to IP VPNs and Ethernet VPNs. In addition, network convergence and technology refreshes demand for common and flexible infrastructure that provides multiple services. Thanks, Luyuan -Original Message- From: Russ Housley hous...@vigilsec.com Date: Saturday, March 23, 2013 3:16 PM To: ietf@ietf.org ietf@ietf.org Cc: m...@ietf.org m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt I wonder if the direction of Section 1.2 can be revised to make it more of an engineering document. It currently says: In recent years, the urgency for moving from traditional transport technologies, such as SONET/SDH, TDM, and ATM, to new packet technologies has been rising. This is largely due to the fast growing demand for bandwidth, which has been fueled by the following factors: ... Please consider an approach that describes the the reasons behind the transition from the network operator and network user perspectives: Traditional transport technologies include SONET/SDH, TDM, and ATM. There is a transition away from these transport technologies to new packet technologies. In addition to the ever increasing demand for bandwidth, the packet technologies offer these advantages: ... The fact that IP networks are being used for new applications and that the legacy devices are getting old does not motivate the transition to packet technologies. The advantages that packet technologies offer for these new applications is the thing that needs to be highlighted here, even if it is just a list of bullets. It seems like the only sentence that addresses this point in Section 1.2 is: It streamlines the operation, reduces the overall complexity, and improves end-to-end convergence. Thanks, Russ
Re: [mpls] Last Call: draft-ietf-mpls-tp-security-framework-07.txt (MPLS-TP Security Framework) to Informational RFC
Barry, Thanks again for your help and support! Luyuan -Original Message- From: Barry Leiba barryle...@computer.org Date: Wednesday, February 6, 2013 1:47 PM To: Luyuan Fang luf...@cisco.com Cc: draft-ietf-mpls-tp-security-framework@tools.ietf.org draft-ietf-mpls-tp-security-framework@tools.ietf.org, m...@ietf.org m...@ietf.org, IETF discussion list ietf@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-security-framework-07.txt (MPLS-TP Security Framework) to Informational RFC Thank you very much for your review and detailed comments/suggestions, and thanks for your discussion. I uploaded the new version that addressed all your comments, as well as Dan's Gen-ART review comments, and acknowledged your help. Thanks for the reply, Luyuan. I'm happy with all the resolutions. Barry
Re: [mpls] Last Call: draft-ietf-mpls-tp-security-framework-07.txt (MPLS-TP Security Framework) to Informational RFC
Hi Barry, Thank you very much for your review and detailed comments/suggestions, and thanks for your discussion. I uploaded the new version that addressed all your comments, as well as Dan's Gen-ART review comments, and acknowledged your help. http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-security-framework-0 8.txt Please see in-line. -Original Message- From: Barry Leiba barryle...@computer.org Date: Monday, February 4, 2013 5:00 AM To: draft-ietf-mpls-tp-security-framework@tools.ietf.org draft-ietf-mpls-tp-security-framework@tools.ietf.org Cc: m...@ietf.org m...@ietf.org, IETF discussion list ietf@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-security-framework-07.txt (MPLS-TP Security Framework) to Informational RFC The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS-TP Security Framework' draft-ietf-mpls-tp-security-framework-07.txt as Informational RFC Some Last Call comments in advance of IESG Evaluation: -- Abstract -- This document is built on RFC5920 MPLS and GMPLS MPLS and GMPLS security framework Bit of a stuttering typo there. [luyuan] Fixed. -- General -- There are lots of abbreviations throughout here that aren't expanded. You do send us to documentation (the last paragraph of Section 1), so I wonder how much we should expect every one to be expanded on first use. But I see OAM, GMPLS, PWE3, PE (with and without S- and T-), GAL, G-ACh, BFD, DoS, LSP. [luyuan] We initially had terminology section, it was taken out during the last call discussion. Based on the comments from you and Dan for Gen-ART, I added the term section back with a new list of terms that are relevant to this document. On the other hand, I'm not sure we want to clutter things up with a lot of expansions that anyone who reads the document will already know. So I'll just leave this as a passing comment. -- Sections 2.1 and 2.2 -- It's a small point, but the diagrams for security reference models 1(b), 2(a), 2(b), and 2(c) aren't labelled exactly as the text states. The bad ones are 2(a) and (b), where the diagrams have SPE1 and the text has S-PE. In the others, it's just a question of a - in the text and none in the diagram. As I say, it's a small point, but I'd prefer it if the text and the diagrams matched exactly; removing the dashes in the text seems easiest (and fixing the 1 in the text for the two S-PE cases). [luyuan] Fixed all. -- Section 3 -- This section discuss various network security threats which are to MPLS-TP and may endanger MPLS-TP networks. Is this missing the word new somewhere? (And make it discusses, while you're fixing that. We'll let the RFC Editor do the which-that change; they need something to do.) [luyuan] Fixed. New text: This section discusses various network security threats that are unique to MPLS-TP and may endanger MPLS-TP networks. A successful attack on a particular MPLS-TP network or on a SP's MPLS-TP infrastructure may cause one or more adverse effects. Yes, that would sort of be the definition of a successful attack, I should think. (You might consider deleting this paragraph.) [luyuan] Removed. - GAL or BFD label manipulation, which includes insertion of false labels, messages modification, deletion, or replay. To make the list clearer, I suggest this: NEW - GAL or BFD label manipulation, which includes insertion of false labels and modification, deletion, or replay of messages. END [luyuan] Used suggested text. - DoS attack through in-band OAM G-ACh/GAL and BFD messages. You mean *excessive*, unproductive messages, of course. Is there a good way to say this that can help someone detect when these messages become a DoS attack, or otherwise give some more information? (Maybe there isn't...) [luyuan] New text: DoS attack through in-band OAM by generating excessive G-ACh/GAL and BFD messages which consume significant bandwidth and potentially cause congestion. When a NMS is used for LSP setup, the attacks to NMS can cause the above effect as well. Although this is not unique to MPLS-TP, but MPLS-TP network can be particularly venerable as static provisioning through NMS is a commonly used model. Vulnerable, not venerable. But I don't understand why the fact that static provisioning through NMS causes any greater vulnerability than otherwise. Can you expand on that a bit? [luyuan] New text: When a NMS is used for LSP setup, the attacks to NMS can cause the above effect as well. Although this is not unique to MPLS-TP, MPLS-TP network can be particularly vulnerable to NMS attack due to the fact that static provisioning through NMS is a commonly used model. In the static provisioning model, a compromised NMS can potentially be comparable to a comprised control plane plus a comprised management plane in the dynamic controlled network model. Observation (including
Re: [mpls] Last Call: draft-ietf-mpls-tp-security-framework-07.txt (MPLS-TP Security Framework) to Informational RFC
Thank you very much for your review and detailed comments/suggestions, and thanks for your discussion. I uploaded the new version that addressed all your comments, as well as Dan's Gen-ART review comments, and acknowledged your help. Thanks for the reply, Luyuan. I'm happy with all the resolutions. Barry
Re: [mpls] Last Call: draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt(LabelSwitched Path (LSP) Ping for IPv6 Pseudowire FECs) toProposed Standard
More thoughts inline tp three times (and apologies for the slow response). - Original Message - From: Mach Chen mach.c...@huawei.com To: t.p. daedu...@btconnect.com; ietf@ietf.org Sent: Wednesday, November 07, 2012 12:24 PM Hi Tom, Many thanks for your comments! Please see my reply inline with [Mach] Best regards, Mach From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] on behalf of t.p. [daedu...@btconnect.com] Sent: Saturday, November 03, 2012 2:05 To: ietf@ietf.org I worry about the allocation of sub-TLVs in this I-D. It calls for The following Sub-TLV changes, which comprise three updates and two additions, are made for two TLV Types in the aforementioned sub- registry: TLV Type 1 for Target FEC Stack, and TLV Type 21 for Reply Path. and it is the Type 21 that worries me. [Mach] Since draft-ietf-mpls-return-path-specified-lsp-ping has already defined the rule and policy on how to inhirent the sub-TLVs from type 1 TLV, IMHO, here it may be no need to explicitly mention how to registry the sub-TLVs for Type 21. So, how about this: The following Sub-TLV changes, which comprise three updates and two additions, are made for TLV Type 1. tp I do not see this rule defined in draft-ietf-mpls-return-path-specified, at least, not for any sub-TLVs that may be defined in future for Type 1 TLVs, that is, that I-D covers the present but not the future and that is what I worry about. The ipv6 I-D as initially written did not take account of return-path-specified and vice versa, so I expect this situation to recur and do not see a good solution to it. /tp IANA has, for Type 21, Reply Path (TEMPORARY - expires 2012-01-20) [draft-ietf-mpls-return-path-specified-lsp-ping] and I am unclear what the rules are about updates to expired, TEMPORARY, allocations. [Mach] As Loa pointed out, the current IANA registry for Type 21 TLV is not reflecting the proposal in [draft-ietf-mpls-return-path-specified-lsp-ping]. tp Yes, and my reading is that the removal of temporary allocations is (yet another) duty of the WG chair, so doubtless that will be taken care of:-) /tp I worry too that [draft-ietf-mpls-return-path-specified-lsp-ping] while confirming the reservation of Type 21 takes a different tack for sub-TLVs, namely According to the guidelines defined in [RFC5226], the sub-TLV range of Reply Path TLV are partitioned as following: 0-31743 - Reserved, and MUST NOT be allocated. so quite what this I-D will do to that I-D worries me. [Mach] This is intended for the Type 21 TLV to have a common part code range shared with Type 1 TLV and a TLV specific code range for its own dedicaed sub-TLV. I think we should have an agreement on this solution :-) tp Yes, we have long had agreement on the general idea of the solution but it is not clear to me that the current wording got that message across, for example to the AD, in which case we need better wording. I realise that this has come up on the MPLS list but I am unsure what the proposed wording now is. In fact, I am unclear whether the change proposed in return-path-specified is intended to apply to all TLVs, present and future - I think that it should, for safety, but the wording is unclear to me on that point Which point is of course nothing to do with the IETF Last Call of ipv6, no need to mention it there, but it seems better to keep it on one thread for the moment. /tp Best regards, Mach And I worry yet more that other I-Ds, such as draft-zjns-mpls-lsp-ping-relay-reply-00 are heading down the track with further updates in this area of the MPLS namespace (except that this particular one seems to have abandoned sub-TLVs). Tom Petch - Original Message - From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Cc: m...@ietf.org Sent: Wednesday, October 24, 2012 9:31 PM The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs' draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt as 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 2012-11-09. 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 Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping and traceroute mechanisms are commonly used to detect and isolate data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. The PW LSP Ping and traceroute elements, however, are not specified for IPv6 address usage. This document extends the PW LSP Ping and traceroute mechanisms so they can be used with IPv6 PWs, and updates RFC 4379. The file can be obtained via
RE: [mpls] Last Call: draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt (LabelSwitched Path (LSP) Ping for IPv6 Pseudowire FECs) toProposed Standard
Hi Tom, Many thanks for your comments! Please see my reply inline with [Mach] Best regards, Mach From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] on behalf of t.p. [daedu...@btconnect.com] Sent: Saturday, November 03, 2012 2:05 To: ietf@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt (LabelSwitched Path (LSP) Ping for IPv6 Pseudowire FECs)toProposed Standard I worry about the allocation of sub-TLVs in this I-D. It calls for The following Sub-TLV changes, which comprise three updates and two additions, are made for two TLV Types in the aforementioned sub- registry: TLV Type 1 for Target FEC Stack, and TLV Type 21 for Reply Path. and it is the Type 21 that worries me. [Mach] Since draft-ietf-mpls-return-path-specified-lsp-ping has already defined the rule and policy on how to inhirent the sub-TLVs from type 1 TLV, IMHO, here it may be no need to explicitly mention how to registry the sub-TLVs for Type 21. So, how about this: The following Sub-TLV changes, which comprise three updates and two additions, are made for TLV Type 1. IANA has, for Type 21, Reply Path (TEMPORARY - expires 2012-01-20) [draft-ietf-mpls-return-path-specified-lsp-ping] and I am unclear what the rules are about updates to expired, TEMPORARY, allocations. [Mach] As Loa pointed out, the current IANA registry for Type 21 TLV is not reflecting the proposal in [draft-ietf-mpls-return-path-specified-lsp-ping]. I worry too that [draft-ietf-mpls-return-path-specified-lsp-ping] while confirming the reservation of Type 21 takes a different tack for sub-TLVs, namely According to the guidelines defined in [RFC5226], the sub-TLV range of Reply Path TLV are partitioned as following: 0-31743 - Reserved, and MUST NOT be allocated. so quite what this I-D will do to that I-D worries me. [Mach] This is intended for the Type 21 TLV to have a common part code range shared with Type 1 TLV and a TLV specific code range for its own dedicaed sub-TLV. I think we should have an agreement on this solution :-) Best regards, Mach And I worry yet more that other I-Ds, such as draft-zjns-mpls-lsp-ping-relay-reply-00 are heading down the track with further updates in this area of the MPLS namespace (except that this particular one seems to have abandoned sub-TLVs). Tom Petch - Original Message - From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Cc: m...@ietf.org Sent: Wednesday, October 24, 2012 9:31 PM The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs' draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt as 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 2012-11-09. 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 Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping and traceroute mechanisms are commonly used to detect and isolate data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. The PW LSP Ping and traceroute elements, however, are not specified for IPv6 address usage. This document extends the PW LSP Ping and traceroute mechanisms so they can be used with IPv6 PWs, and updates RFC 4379. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp-ping/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp-ping/ballot/ No IPR declarations have been submitted directly on this I-D. ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls
Re: [mpls] Last Call: draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt (LabelSwitched Path (LSP) Ping for IPv6 Pseudowire FECs) toProposed Standard
I worry about the allocation of sub-TLVs in this I-D. It calls for The following Sub-TLV changes, which comprise three updates and two additions, are made for two TLV Types in the aforementioned sub- registry: TLV Type 1 for Target FEC Stack, and TLV Type 21 for Reply Path. and it is the Type 21 that worries me. IANA has, for Type 21, Reply Path (TEMPORARY - expires 2012-01-20) [draft-ietf-mpls-return-path-specified-lsp-ping] and I am unclear what the rules are about updates to expired, TEMPORARY, allocations. I worry too that [draft-ietf-mpls-return-path-specified-lsp-ping] while confirming the reservation of Type 21 takes a different tack for sub-TLVs, namely According to the guidelines defined in [RFC5226], the sub-TLV range of Reply Path TLV are partitioned as following: 0-31743 - Reserved, and MUST NOT be allocated. so quite what this I-D will do to that I-D worries me. And I worry yet more that other I-Ds, such as draft-zjns-mpls-lsp-ping-relay-reply-00 are heading down the track with further updates in this area of the MPLS namespace (except that this particular one seems to have abandoned sub-TLVs). Tom Petch - Original Message - From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Cc: m...@ietf.org Sent: Wednesday, October 24, 2012 9:31 PM The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs' draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt as 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 2012-11-09. 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 Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping and traceroute mechanisms are commonly used to detect and isolate data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. The PW LSP Ping and traceroute elements, however, are not specified for IPv6 address usage. This document extends the PW LSP Ping and traceroute mechanisms so they can be used with IPv6 PWs, and updates RFC 4379. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp-ping/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp-ping/ballot/ No IPR declarations have been submitted directly on this I-D. ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls
Re: [mpls] Last Call: draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt (LabelSwitched Path (LSP) Ping for IPv6 Pseudowire FECs) toProposed Standard
Tom, On Nov 2, 2012, at 2:05 PM, t.p. daedu...@btconnect.com wrote: I worry about the allocation of sub-TLVs in this I-D. Thanks for the comments. I share worries about keeping synchronicity between sub-registries in this fashion. It calls for The following Sub-TLV changes, which comprise three updates and two additions, are made for two TLV Types in the aforementioned sub- registry: TLV Type 1 for Target FEC Stack, and TLV Type 21 for Reply Path. and it is the Type 21 that worries me. Right -- the allocations under Type 1 are straightforward. But the allocations under Type 21 seem to be standing over quicksand. IANA has, for Type 21, Reply Path (TEMPORARY - expires 2012-01-20) [draft-ietf-mpls-return-path-specified-lsp-ping] and I am unclear what the rules are about updates to expired, TEMPORARY, allocations. I worry too that [draft-ietf-mpls-return-path-specified-lsp-ping] while confirming the reservation of Type 21 takes a different tack for sub-TLVs, namely According to the guidelines defined in [RFC5226], the sub-TLV range of Reply Path TLV are partitioned as following: 0-31743 - Reserved, and MUST NOT be allocated. so quite what this I-D will do to that I-D worries me. Perhaps the best approach is to decouple. Have all Type 21 allocations under draft-ietf-mpls-return-path-specified-lsp-ping and have that point to the RFC from draft-ietf-mpls-ipv6-pw-lsp-ping if needed (and it can take a snapshot of the sub-registry when it will be stable.) Thanks, -- Carlos. And I worry yet more that other I-Ds, such as draft-zjns-mpls-lsp-ping-relay-reply-00 are heading down the track with further updates in this area of the MPLS namespace (except that this particular one seems to have abandoned sub-TLVs). Tom Petch - Original Message - From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Cc: m...@ietf.org Sent: Wednesday, October 24, 2012 9:31 PM The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs' draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt as 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 2012-11-09. 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 Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping and traceroute mechanisms are commonly used to detect and isolate data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. The PW LSP Ping and traceroute elements, however, are not specified for IPv6 address usage. This document extends the PW LSP Ping and traceroute mechanisms so they can be used with IPv6 PWs, and updates RFC 4379. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp-ping/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp-ping/ballot/ No IPR declarations have been submitted directly on this I-D. ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls
Re: [mpls] point 3 in... RE: Questions about draft-betts-itu-oam-ach-code-point
All (taking chair hat off), I agree with Ross's comments below that if the document is last called it should go through a wg last call (pwe3 and mpls) and through an IETF last call. I agree that these last calls could be in parallel is necessary, but I believe that running the wg last call first and the IETF last call would be beneficial. Given that we have a stable document with stable references to last call. /Loa On 2012-01-13 06:43, Ross Callon wrote: Adrian wrote: My review of the write-up and discussions... 3. There seems to be quite a feeling on the mailing lists that this document should be run through the MPLS working group. The write-up makes a case for progressing it as AD sponsored. As far as I can see, the main assertions to answer are as follows. Do you have a view on these points before I make a decision on what to do? a. This is a proposal to use an MPLS code point and so is part of MPLS by definition. b. The type of network being managed by the OAM described in G.8113.1 is an MPLS network. Therefore, this is clearly relevant to the MPLS working . Do you object to this going through the MPLS on principle, or were you just hoping to save the WG the work? If the latter, and if the WG wants to look at the draft, the easiest approach seems to be to redirect the work to the working group. My personal opinion (speaking as an individual)... It is pretty clear that there is a lot of interest in this topic in the MPLS WG. It also is clear that this proposal is very much about MPLS. Thus draft-betts-itu-oam-ach-code-point needs to be last called in the MPLS WG. It seems clear that the document also needs IETF last call. I assume this means that one last call would be posted to both the MPLS and IETF WG lists. It seems that this same last call should also be copied to the PWE3 list. Ross ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- 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: [mpls] point 3 in... RE: Questions about draft-betts-itu-oam-ach-code-point
Also taking my chair hat off ... as Malcolm stated that G.8113.1 applies to PWs, and the requested allocation is in a registry that originated in the PWE3 working group, I agree that a PWE3 WG last call is warranted. This could certainly take place in parallel with the MPLS WG last call. Cheers, Andy On Fri, Jan 13, 2012 at 5:46 AM, Loa Andersson l...@pi.nu wrote: All (taking chair hat off), I agree with Ross's comments below that if the document is last called it should go through a wg last call (pwe3 and mpls) and through an IETF last call. I agree that these last calls could be in parallel is necessary, but I believe that running the wg last call first and the IETF last call would be beneficial. Given that we have a stable document with stable references to last call. /Loa On 2012-01-13 06:43, Ross Callon wrote: Adrian wrote: My review of the write-up and discussions... 3. There seems to be quite a feeling on the mailing lists that this document should be run through the MPLS working group. The write-up makes a case for progressing it as AD sponsored. As far as I can see, the main assertions to answer are as follows. Do you have a view on these points before I make a decision on what to do? a. This is a proposal to use an MPLS code point and so is part of MPLS by definition. b. The type of network being managed by the OAM described in G.8113.1 is an MPLS network. Therefore, this is clearly relevant to the MPLS working . Do you object to this going through the MPLS on principle, or were you just hoping to save the WG the work? If the latter, and if the WG wants to look at the draft, the easiest approach seems to be to redirect the work to the working group. My personal opinion (speaking as an individual)... It is pretty clear that there is a lot of interest in this topic in the MPLS WG. It also is clear that this proposal is very much about MPLS. Thus draft-betts-itu-oam-ach-code-point needs to be last called in the MPLS WG. It seems clear that the document also needs IETF last call. I assume this means that one last call would be posted to both the MPLS and IETF WG lists. It seems that this same last call should also be copied to the PWE3 list. Ross ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- 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 ___ 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] Questions about draft-betts-itu-oam-ach-code-point
Inline tp Tom Petch From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of ext Thomas Nadeau Sent: Thursday, January 12, 2012 10:30 PM To: John E Drake Cc: m...@ietf.org; draft-betts-itu-oam-ach-code-po...@tools.ietf.org; ietf@ietf.org; ietf-boun...@ietf.org On Jan 12, 2012, at 3:18 PM, John E Drake wrote: Snipped, comments inline. 3. There seems to be quite a feeling on the mailing lists that this document should be run through the MPLS working group. The write-up makes a case for progressing it as AD sponsored. As far as I can see, the main assertions to answer are as follows. Do you have a view on these points before I make a decision on what to do? a. This is a proposal to use an MPLS code point and so is part of MPLS by definition. b. The type of network being managed by the OAM described in G.8113.1 is an MPLS network. Therefore, this is clearly relevant to the MPLS working . Do you object to this going through the MPLS on principle, or were you just hoping to save the WG the work? If the latter, and if the WG wants to look at the draft, the easiest approach seems to be to redirect the work to the working group. [MB] G.8113.1 supports a subset of the functions defined in draft-bhh-mpls-tp-oam-y1731-08. The -00 version was posted in March 2009, the draft was presented at several meetings in 2009 and early 2010 and had extensive discussion on the MPLS mailing list. However, the MPLS WG have, by rough consensus, adopted a different approach. Therefore, further review by the MPLS WG is of little value. [JD] Um, I don't think so. Since, as you state above, G.8113.1 is effectively draft-bhh and since draft-bhh was explicitly rejected by the MPLS WG, your draft, which requests a code point for G.8113.1, is basically an attempt to subvert the decision by the MPLS WG to reject draft-bhh by attempting to bypass the WG with an individual submission. So, I think it is clear that your draft belongs in the MPLS WG. tp This I think is the danger of having the MPLS WG review the document. draft-bhh was rejected by the MPLS WG and that is history. Another SDO wants to standardise the technology and, while the IETF may think that that is the wrong approach, that is not our decision. We do however lay claim to control of the code points which would make this technology easier to deploy and that is what this I-D requests. Unless there is some inherent problem in having a code point that invokes a different technology, then there is no reason why we should reject this reasonable request. The risk is that the request for a code point will degenerate into a draft-bhh, now in its G. form, bashing exercise, which can have no positive outcome. We have already decided that draft-bhh is not something we want to standardise, we have already said that having two competing standards is not a good idea (which the current draft recognises); allocating a code point does no more than let the market place decide which approach is better. Tom Petch Incidentally, the MPLS/GMPLS change process was put in place in reaction to the publication of another individual submission, RFC3474, which was completely non-interoperable with standard RSVP, a surprisingly similar situation. Well said John. I couldn't have put it any better myself, and so agree with that statement %100. --Tom ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] Questions about draft-betts-itu-oam-ach-code-point
Hi, I fully agree with John and Tom. G.8113.1 intends to provide an OAM solution for MPLS-TP networks and the discussion on your draft completely belongs in the MPLS WG and also in the PWE3 WG. Two more points: * Malcolm, you say that that the requested code point is not limited to G.8113.1...other uses are not prohibited by this draft. I think it should be very clear for what exactly use it is requested. * Malcolm, you mention that the value of the code point corresponds to the Ethertype used for Ethernet OAMare you sure you approached the appropriate organization for the code point you are looking for? It seems that you either need to approach the IEEE and look for an EtherType or simply use PWs to transmit Ethernet OAM. Best regards, Nurit From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of ext Thomas Nadeau Sent: Thursday, January 12, 2012 10:30 PM To: John E Drake Cc: m...@ietf.org; draft-betts-itu-oam-ach-code-po...@tools.ietf.org; ietf@ietf.org; ietf-boun...@ietf.org Subject: Re: [mpls] Questions about draft-betts-itu-oam-ach-code-point On Jan 12, 2012, at 3:18 PM, John E Drake wrote: Snipped, comments inline. 3. There seems to be quite a feeling on the mailing lists that this document should be run through the MPLS working group. The write-up makes a case for progressing it as AD sponsored. As far as I can see, the main assertions to answer are as follows. Do you have a view on these points before I make a decision on what to do? a. This is a proposal to use an MPLS code point and so is part of MPLS by definition. b. The type of network being managed by the OAM described in G.8113.1 is an MPLS network. Therefore, this is clearly relevant to the MPLS working . Do you object to this going through the MPLS on principle, or were you just hoping to save the WG the work? If the latter, and if the WG wants to look at the draft, the easiest approach seems to be to redirect the work to the working group. [MB] G.8113.1 supports a subset of the functions defined in draft-bhh-mpls-tp-oam-y1731-08. The -00 version was posted in March 2009, the draft was presented at several meetings in 2009 and early 2010 and had extensive discussion on the MPLS mailing list. However, the MPLS WG have, by rough consensus, adopted a different approach. Therefore, further review by the MPLS WG is of little value. [JD] Um, I don't think so. Since, as you state above, G.8113.1 is effectively draft-bhh and since draft-bhh was explicitly rejected by the MPLS WG, your draft, which requests a code point for G.8113.1, is basically an attempt to subvert the decision by the MPLS WG to reject draft-bhh by attempting to bypass the WG with an individual submission. So, I think it is clear that your draft belongs in the MPLS WG. Incidentally, the MPLS/GMPLS change process was put in place in reaction to the publication of another individual submission, RFC3474, which was completely non-interoperable with standard RSVP, a surprisingly similar situation. Well said John. I couldn't have put it any better myself, and so agree with that statement %100. --Tom ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Re: [mpls] unresolved technical concerns
Alessandro, Most of the comments I remember reading were of the form we don't like MPLS OAM because it has 'major unresolved technical concerns' and draft-bhh is *so* much better. I.e., they were neither constructive nor actionable. Thanks, John -Original Message- From: erminio.ottone...@libero.it [mailto:erminio.ottone...@libero.it] Sent: Wednesday, October 19, 2011 1:50 PM To: John E Drake; Luyuan Fang (lufang); Alexander Vainshtein; D'Alessandro Alessandro Gerardo; Stewart Bryant (stbryant) Cc: m...@ietf.org; ietf@ietf.org Subject: R: Re: [mpls] unresolved technical concerns What about going into the mailing list and LS logs and read the comments provided by several service providers before asking for them being repeated again in a I-D that will fate share with the past comments (i.e., ignored)? The comments have been already made. It is now the duty of the party which has so far ignored them to provide an answer. It is also so easy to keep ingnoring drafts and technical comments and request people to continue to produce drafts Messaggio originale Da: jdr...@juniper.net Data: 5-ott-2011 23.20 A: Luyuan Fang (lufang)luf...@cisco.com, Alexander VainshteinAlexander. vainsht...@ecitele.com, D'Alessandro Alessandro Gerardoalessandro. dalessan...@telecomitalia.it, Stewart Bryant (stbryant)stbry...@cisco.com Cc: m...@ietf.orgm...@ietf.org, ietf@ietf.orgietf@ietf.org Ogg: Re: [mpls] unresolved technical concerns That's because it is *so* much easier to just keep mumbling 'major unresolved technical concerns'. I expect it is something learned in Yoga class. -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Luyuan Fang (lufang) Sent: Wednesday, October 05, 2011 5:11 PM To: Alexander Vainshtein; D'Alessandro Alessandro Gerardo; Stewart Bryant (stbryant) Cc: m...@ietf.org; ietf@ietf.org Subject: Re: [mpls] unresolved technical concerns Yep. We are going in circles again. We need to see technical details on the issues documented in an I-D as Stewart suggested. Don't remember seeing such document either. Luyuan -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, October 05, 2011 4:18 PM To: D'Alessandro Alessandro Gerardo; Stewart Bryant (stbryant) Cc: ietf@ietf.org; m...@ietf.org Subject: Re: [mpls] unresolved technical concerns Dear Alessandro, Lots of thanks for a prompt response. Unfortunately your response does not really help (at least, me) to identify even a single specific technical issue. You may attribute it to my faulty memory, but I could not remember any. Presenting these cocerns in the form of an I-D as suggested by Stewart would be the right first step. My 2c Sasha From: D'Alessandro Alessandro Gerardo [alessandro.dalessan...@telecomitalia.it] Sent: Wednesday, October 05, 2011 6:54 PM To: stbry...@cisco.com; Alexander Vainshtein Cc: adr...@olddog.co.uk; m...@ietf.org; ietf@ietf.org Subject: unresolved technical concerns Dear Stewart, Dear Sasha, I think there are already enough contributions in that direction I (with many other experts) contributed to in the form of IETF mailing list discussion and ITU-T liaisons. Unfortunately I regret to say that some questions for clarification and concerns risen in those emails (for sure some of mine) still remain without an answer. At the same time, some comments provided by ITU-T liaisons still remain unresolved. 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
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: [mpls] R: FW: Last Call:draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons forSelecting a Single Solution for MPLS-TP OAM) to Informational RFC
Hi, Same here: Yes/Support. Cyril -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext John E Drake Sent: Thursday, October 06, 2011 1:11 PM To: David Sinicrope; 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 forSelecting 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] R: FW:LastCall: draft-sprecher-mpls-tp-oam-considerations-01.txt(TheReasons for Selecting a Single Solution for MPLS-TP OAM)toInformational RFC
Hi, I support publication of this document, although I do have some comments on the composition of sections 4 5 that I will privately provide the editors. Yaacov Weingarten -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of ext Luyuan Fang (lufang) Sent: Thursday, October 06, 2011 5:24 PM To: John E Drake; David Sinicrope; David Allan I Cc: m...@ietf.org; ietf@ietf.org Subject: Re: [mpls] R: FW:LastCall: draft-sprecher-mpls-tp-oam-considerations-01.txt(TheReasons for Selecting a Single Solution for MPLS-TP OAM)toInformational RFC Same here. I support publication of the draft. Luyuan -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of John E Drake Sent: Thursday, October 06, 2011 7:11 AM To: David Sinicrope; David Allan I Cc: m...@ietf.org; ietf@ietf.org Subject: Re: [mpls] R: FW: LastCall: draft-sprecher-mpls-tp-oam- considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational 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 ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] 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: [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] 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
RE: [mpls] unresolved technical concerns
Yep. We are going in circles again. We need to see technical details on the issues documented in an I-D as Stewart suggested. Don't remember seeing such document either. Luyuan -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, October 05, 2011 4:18 PM To: D'Alessandro Alessandro Gerardo; Stewart Bryant (stbryant) Cc: ietf@ietf.org; m...@ietf.org Subject: Re: [mpls] unresolved technical concerns Dear Alessandro, Lots of thanks for a prompt response. Unfortunately your response does not really help (at least, me) to identify even a single specific technical issue. You may attribute it to my faulty memory, but I could not remember any. Presenting these cocerns in the form of an I-D as suggested by Stewart would be the right first step. My 2c Sasha From: D'Alessandro Alessandro Gerardo [alessandro.dalessan...@telecomitalia.it] Sent: Wednesday, October 05, 2011 6:54 PM To: stbry...@cisco.com; Alexander Vainshtein Cc: adr...@olddog.co.uk; m...@ietf.org; ietf@ietf.org Subject: unresolved technical concerns Dear Stewart, Dear Sasha, I think there are already enough contributions in that direction I (with many other experts) contributed to in the form of IETF mailing list discussion and ITU-T liaisons. Unfortunately I regret to say that some questions for clarification and concerns risen in those emails (for sure some of mine) still remain without an answer. At the same time, some comments provided by ITU-T liaisons still remain unresolved. 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. 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. ___ 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
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: [mpls] R: FW: LastCall: draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC
Same here. I support publication of the draft. Luyuan -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of John E Drake Sent: Thursday, October 06, 2011 7:11 AM To: David Sinicrope; David Allan I Cc: m...@ietf.org; ietf@ietf.org Subject: Re: [mpls] R: FW: LastCall: draft-sprecher-mpls-tp-oam- considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational 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 ___ 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
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: [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: [mpls] R: FW: LastCall: draft-sprecher-mpls-tp-oam-considerations-01.txt(The Reasons for Selecting a Single Solution for MPLS-TP OAM
3) The global wide application of Ethernet services requires that the operator’s network must support Y.1731 Ethernet OAM, to guaranteeing the SLA for customers. Although many operators had expressed their requirements for MPLS-TP OAM using draft-bhh/G.8113.1 in IETF meetings and mail-list, but these were always been ignored. The IETF is concerned with the design of an MPLS technology, not an Ethernet technology. What technical problem exists with the IETF OAM solution that prevents the operator from guaranteeing the SLA for customers? Stewart ___ 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
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
RE: [mpls] unresolved technical concerns
That's because it is *so* much easier to just keep mumbling 'major unresolved technical concerns'. I expect it is something learned in Yoga class. -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Luyuan Fang (lufang) Sent: Wednesday, October 05, 2011 5:11 PM To: Alexander Vainshtein; D'Alessandro Alessandro Gerardo; Stewart Bryant (stbryant) Cc: m...@ietf.org; ietf@ietf.org Subject: Re: [mpls] unresolved technical concerns Yep. We are going in circles again. We need to see technical details on the issues documented in an I-D as Stewart suggested. Don't remember seeing such document either. Luyuan -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, October 05, 2011 4:18 PM To: D'Alessandro Alessandro Gerardo; Stewart Bryant (stbryant) Cc: ietf@ietf.org; m...@ietf.org Subject: Re: [mpls] unresolved technical concerns Dear Alessandro, Lots of thanks for a prompt response. Unfortunately your response does not really help (at least, me) to identify even a single specific technical issue. You may attribute it to my faulty memory, but I could not remember any. Presenting these cocerns in the form of an I-D as suggested by Stewart would be the right first step. My 2c Sasha From: D'Alessandro Alessandro Gerardo [alessandro.dalessan...@telecomitalia.it] Sent: Wednesday, October 05, 2011 6:54 PM To: stbry...@cisco.com; Alexander Vainshtein Cc: adr...@olddog.co.uk; m...@ietf.org; ietf@ietf.org Subject: unresolved technical concerns Dear Stewart, Dear Sasha, I think there are already enough contributions in that direction I (with many other experts) contributed to in the form of IETF mailing list discussion and ITU-T liaisons. Unfortunately I regret to say that some questions for clarification and concerns risen in those emails (for sure some of mine) still remain without an answer. At the same time, some comments provided by ITU-T liaisons still remain unresolved. 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. 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
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: [mpls] FW: Last Call:draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC
Hi, 1. 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. MPLS-TP is subset of MPLS, MPLS is old mpls developed before MPLS-TP in 2008 or include MPLS-TP developed this years and in the future? MPLS-TP is for transport network, SDH/OTN/Etherent is transport network, it should be shown capability to transport network. 1.1 The standardization process within the IETF allows for the continued analysis of whether the OAM solutions under development meet the documented requirements, and facilitates the addition of new requirements if any are discovered. It is not the purpose of this document to analyze the correctness of the selection of specific OAM solutions. This document is intended to explain why it would be unwise to standardize multiple solutions for MPLS-TP OAM, and to show how the existence of multiple solutions would complicate MPLS-TP development and deployment making networks more expensive to build, less stable, and more costly to operate. According to JWT report, MPLS-TP is joint standardized by IETF and ITU-T, it is not right for someone decide solution for IETF and ITU-T. 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. A report was subsequently submitted to the IETF MPLS Working Group at the Stockholm IETF meeting in July 2009. The guidelines drawn up by the design team have played an important role in the creation of a coherent MPLS-TP OAM solution. MEAD team's decision has never been send to ITU-T for comments, ITU-T have got nothing information about it. 1.2. The Development of a Parallel MPLS-TP OAM Solution The first of these was discussed within the IETF's MPLS working group where precedence was given to adherence to the JWT's recommendation to select a solution that reused as far as possible pre-existing MPLS tools. Additionally, it was considered that consistency with encodings and mechanisms used in MPLS was of greater importance. Many operators ask MPLS-TP OAM shown capacity to Ethernet, you can see draft-bhh-mpls-tp-oam-y1731. at least 9 provdiders support it. JWT report don't said anything about one solution, it is a start point to develop solution, IETF and ITU-T don't explore to public, one solution should be taken. 3.6 It should be noted that, in the long-run, it is the end-users who pay the price for the additional development costs and any network instability that arises. authors are come from vendors, they are not end users, which some venders want to push their own solutions. we should hear opinons from providers? let providers show their consideration on OAM, there is a IETF providers' draft about OAM consideration, you can refer to draft-fang-mpls-tp-oam-considerations, it is a pure providers' draft, some considerations are listed there! 5.1 for SDH/SONET as example, it work well in the network, phone call between Europe to US work very well, I am wondering author should known some history about SDH and SONET. 6. Potential Models For Coexistence In transport network, overlay model is usually used, it work very well. B.R. Feng -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: 2011年9月27日 5:58 To: m...@ietf.org Subject: [mpls] FW: Last Call:draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational 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
RE: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard
Yoshinori, et al, On thinking about this a little further, and considering that this is a recurring question, it seems likely that there is ambiguity that should be addressed. What I propose to do is add the following to the end of section 2.1.1 that says (something along the lines of): = 'Including this TLV, with one or the other IF_Num (but not both) set to a non-zero value, in a request message that also includes a destination identifier TLV (as described in section 2.2.3), is sufficient to identify the per-interface MIP in section 7.3 of MPLS-TP Identifiers. Inclusion of this TLV with both IF_Num fields set to zero would be interpretted as specifying neither an ingress, nor an egress, interface. Note that this is the same as not including the TLV, hence including this TLV with both IF_Num values set to zero is NOT RECOMMENDED. Including this TLV with both IF_NUM fields set to a non-zero value will result in the responder sending a Return Code of 5 (Downstream Mapping Mis-match) if either IF_Num is incorrect for this LSP or PW.' = The above text is intended for clarification, and to remove potential for ambiguity. The above interpretations are based on procedures spelled out in RFC 4379, section 4.4 (Receiving an MPLS Echo Request). Hence this text does not substantively change the content of the draft in this respect. I believe this should clarify the point you were hoping we could clarify. Please let me know if it does not... -- Eric -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Eric Gray Sent: Sunday, September 04, 2011 11:35 PM To: Yoshinori Koike; ietf@ietf.org Cc: m...@ietf.org; 'IETF-Announce' Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard Yoshinori, The DSMAP/DDMAP was explicitly added to make it possible to direct the implementation to respond to the echo request as if it were directed to a specific interface (either the egress or ingress interface). This interface-specific echo request is what I believe folks are referring to as per-interface. This - in effect - is the primary use for the object in this draft, so any explicit statement to the effect that this is the case would be redundant. While the object includes fields for both an ingress and egress interface, when being used to direct the implementation to respond as if the echo request were directed to a specific interface, only one of these fields would contain valid info. It is possible that both interface numbers are valid. In this case, the object cannot be used for what you are calling a per-interface echo request. However, this case may be useful if - for example - the intention is to verify that the LSP is using this particular interface mapping at this node (i.e. - the request is attempting to ascertain if this is the correct mapping for the LSP). All of this is fairly intuitive to anyone who has read the draft and is reasonably familiar with the technology and protocols involved. This draft is a protocol specification, not a tutorial. As for what may be said in any other draft that is still in the process of being written, that is an issue that is not in scope for this draft. -- Eric -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Yoshinori Koike Sent: Thursday, August 25, 2011 12:35 PM To: ietf@ietf.org Cc: m...@ietf.org; 'IETF-Announce' Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard Hi, I would like to propose that this draft explicitly stipulate whether or not it covers per-interface model. I think it is essential to avoid confusion and clarify the appropriate I-D to discuss OAM solutions for the per-interface model. Per-interface model is one of the two OAM maintenance models in MPLS-TP networks which is specified in section 3 of draft-ietf-mpls-tp-oam-framework. The solution for the per-interface model is under discussion also in the per-interface MIP draft ( http://tools.ietf.org/html/draft-farrel-mpls-tp-mip-mep-map-04 ). If the on-demand-cv-06 covers the OAM solution for per-interface model, the discussion for on-demand CV and route tracing must be removed from the mip-mep-map draft. Otherwise, the mip-mep-map draft has to cover the solutions for on-demand CV and route tracing. I also think that it is important to clarify the comments from Mr. Zhenlong Cui in the draft, whose email is attached at the bottom. It is important to make clear for what purpose the IF_Num is used. It also seems important to clarify the responder's behavior
RE: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard
Zhenlong, I responded to this as part of a response to Yoshinori Koike. If the intention of the requesting MEP is to specify a specific interface, then the appropriate IF_NUM would be set to the IF_NUM of that interface. The format used allows either IF_NUM to be set. If only one is intended (as in the per-interface case), then only that IF_NUM would be set (the other would be set to Zero). There is at least one case where setting both may be useful. Also, while it is not useful to include this TLV if neither is set, this is not explicitly disallowed. As you may have seen, the use of IF_NUM - together with the destination identifier - exactly matches the way that MIP ID is defined in section 7.3 of MPLS-TP Identifiers. Hence the combination of Destination Identifier and DSMAP or DDMAP TLVs - with a specific interface's IF_NUM set - is clearly sufficient to identify the per-interface MIP. -- Eric -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Zhenlong Cui Sent: Thursday, August 25, 2011 2:17 AM To: ietf@ietf.org; 'IETF-Announce' Cc: m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard Hi, I have sent some questions regarding the IF_Num of DSMAP TLV before. I'd like to make sure it is not lost. 2.1. New address type for Downstream Mapping TLV The new address type indicates that no address is present in the DSMAP or DDMAP TLV. However, IF_Num information (see definition of IF_NUM in [I-D.ietf-mpls-tp-identifiers]) for both ingress and egress interfaces, as well as multipath information is included in the format and MAY be present. I believe the IF_Num can be used for per-interface MIP model. But I'm not sure why we need use both ingress IF_Num and egress IF_Num in a DSMAP TLV. I can't find this case (Ingress_IF::Egress_IF) in [I-D.ietf-mpls-tp-identifiers]. e.g.) the following are defined in [I-D.ietf-mpls-tp-identifiers] using IF_Num, but there is no Ingress_IF::Egress_IF. - IF_ID IF_ID is a 64-bit identifier formed as Node_ID::IF_Num. - MIP ID For a MIP which is associated with particular interface, we simply use the IF_ID (see Section 4) of the interfaces which are cross- connected. If have any special means in the IF_Num, I think MUST mention it clearly. Also I feeling that this draft have to clarify the responder's behavior for each IF information of the IF_Num. Best regards, zhenlong -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The IESG Sent: Thursday, August 11, 2011 10:46 PM To: IETF-Announce Cc: m...@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS On-demand Connectivity Verification and Route Tracing' draft-ietf-mpls-tp-on-demand-cv-06.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-08-25. 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 Label Switched Path Ping (LSP-Ping) is an existing and widely deployed Operations, Administration and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP-Ping so that LSP- Ping can be used for On-demand Connectivity Verification of MPLS Transport Profile (MPLS-TP) LSPs and Pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP-Ping to perform Connectivity Verification and Route Tracing functions in MPLS-TP networks. Finally this document updates RFC 4379 by adding a new address type and requesting an IANA registry. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ No IPR declarations have been submitted directly on this I-D. ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard
Yoshinori, The DSMAP/DDMAP was explicitly added to make it possible to direct the implementation to respond to the echo request as if it were directed to a specific interface (either the egress or ingress interface). This interface-specific echo request is what I believe folks are referring to as per-interface. This - in effect - is the primary use for the object in this draft, so any explicit statement to the effect that this is the case would be redundant. While the object includes fields for both an ingress and egress interface, when being used to direct the implementation to respond as if the echo request were directed to a specific interface, only one of these fields would contain valid info. It is possible that both interface numbers are valid. In this case, the object cannot be used for what you are calling a per-interface echo request. However, this case may be useful if - for example - the intention is to verify that the LSP is using this particular interface mapping at this node (i.e. - the request is attempting to ascertain if this is the correct mapping for the LSP). All of this is fairly intuitive to anyone who has read the draft and is reasonably familiar with the technology and protocols involved. This draft is a protocol specification, not a tutorial. As for what may be said in any other draft that is still in the process of being written, that is an issue that is not in scope for this draft. -- Eric -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Yoshinori Koike Sent: Thursday, August 25, 2011 12:35 PM To: i...@ietf.org Cc: m...@ietf.org; 'IETF-Announce' Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard Hi, I would like to propose that this draft explicitly stipulate whether or not it covers per-interface model. I think it is essential to avoid confusion and clarify the appropriate I-D to discuss OAM solutions for the per-interface model. Per-interface model is one of the two OAM maintenance models in MPLS-TP networks which is specified in section 3 of draft-ietf-mpls-tp-oam-framework. The solution for the per-interface model is under discussion also in the per-interface MIP draft ( http://tools.ietf.org/html/draft-farrel-mpls-tp-mip-mep-map-04 ). If the on-demand-cv-06 covers the OAM solution for per-interface model, the discussion for on-demand CV and route tracing must be removed from the mip-mep-map draft. Otherwise, the mip-mep-map draft has to cover the solutions for on-demand CV and route tracing. I also think that it is important to clarify the comments from Mr. Zhenlong Cui in the draft, whose email is attached at the bottom. It is important to make clear for what purpose the IF_Num is used. It also seems important to clarify the responder's behavior, because the ambiguity will definitely lead to interoperability issues. Thank you in advance. Best regards, Yoshinori Koike (2011/08/25 15:17), Zhenlong Cui wrote: Hi, I have sent some questions regarding the IF_Num of DSMAP TLV before. I'd like to make sure it is not lost. 2.1. New address type for Downstream Mapping TLV The new address type indicates that no address is present in the DSMAP or DDMAP TLV. However, IF_Num information (see definition of IF_NUM in [I-D.ietf-mpls-tp-identifiers]) for both ingress and egress interfaces, as well as multipath information is included in the format and MAY be present. I believe the IF_Num can be used for per-interface MIP model. But I'm not sure why we need use both ingress IF_Num and egress IF_Num in a DSMAP TLV. I can't find this case (Ingress_IF::Egress_IF) in [I-D.ietf-mpls-tp-identifiers]. e.g.) the following are defined in [I-D.ietf-mpls-tp-identifiers] using IF_Num, but there is no Ingress_IF::Egress_IF. - IF_ID IF_ID is a 64-bit identifier formed as Node_ID::IF_Num. - MIP ID For a MIP which is associated with particular interface, we simply use the IF_ID (see Section 4) of the interfaces which are cross- connected. If have any special means in the IF_Num, I think MUST mention it clearly. Also I feeling that this draft have to clarify the responder's behavior for each IF information of the IF_Num. Best regards, zhenlong -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The IESG Sent: Thursday, August 11, 2011 10:46 PM To: IETF-Announce Cc: m...@ietf.org Subject: [mpls] Last Call:draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS On-demand Connectivity Verification and Route Tracing' draft-ietf
RE: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard
Zhenlong, I responded to this as part of a response to Yoshinori Koike. If the intention of the requesting MEP is to specify a specific interface, then the appropriate IF_NUM would be set to the IF_NUM of that interface. The format used allows either IF_NUM to be set. If only one is intended (as in the per-interface case), then only that IF_NUM would be set (the other would be set to Zero). There is at least one case where setting both may be useful. Also, while it is not useful to include this TLV if neither is set, this is not explicitly disallowed. As you may have seen, the use of IF_NUM - together with the destination identifier - exactly matches the way that MIP ID is defined in section 7.3 of MPLS-TP Identifiers. Hence the combination of Destination Identifier and DSMAP or DDMAP TLVs - with a specific interface's IF_NUM set - is clearly sufficient to identify the per-interface MIP. -- Eric -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Zhenlong Cui Sent: Thursday, August 25, 2011 2:17 AM To: i...@ietf.org; 'IETF-Announce' Cc: m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard Hi, I have sent some questions regarding the IF_Num of DSMAP TLV before. I'd like to make sure it is not lost. 2.1. New address type for Downstream Mapping TLV The new address type indicates that no address is present in the DSMAP or DDMAP TLV. However, IF_Num information (see definition of IF_NUM in [I-D.ietf-mpls-tp-identifiers]) for both ingress and egress interfaces, as well as multipath information is included in the format and MAY be present. I believe the IF_Num can be used for per-interface MIP model. But I'm not sure why we need use both ingress IF_Num and egress IF_Num in a DSMAP TLV. I can't find this case (Ingress_IF::Egress_IF) in [I-D.ietf-mpls-tp-identifiers]. e.g.) the following are defined in [I-D.ietf-mpls-tp-identifiers] using IF_Num, but there is no Ingress_IF::Egress_IF. - IF_ID IF_ID is a 64-bit identifier formed as Node_ID::IF_Num. - MIP ID For a MIP which is associated with particular interface, we simply use the IF_ID (see Section 4) of the interfaces which are cross- connected. If have any special means in the IF_Num, I think MUST mention it clearly. Also I feeling that this draft have to clarify the responder's behavior for each IF information of the IF_Num. Best regards, zhenlong -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The IESG Sent: Thursday, August 11, 2011 10:46 PM To: IETF-Announce Cc: m...@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS On-demand Connectivity Verification and Route Tracing' draft-ietf-mpls-tp-on-demand-cv-06.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 i...@ietf.org mailing lists by 2011-08-25. 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 Label Switched Path Ping (LSP-Ping) is an existing and widely deployed Operations, Administration and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP-Ping so that LSP- Ping can be used for On-demand Connectivity Verification of MPLS Transport Profile (MPLS-TP) LSPs and Pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP-Ping to perform Connectivity Verification and Route Tracing functions in MPLS-TP networks. Finally this document updates RFC 4379 by adding a new address type and requesting an IANA registry. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ No IPR declarations have been submitted directly on this I-D. ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RE: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard
Yoshinori, The DSMAP/DDMAP was explicitly added to make it possible to direct the implementation to respond to the echo request as if it were directed to a specific interface (either the egress or ingress interface). This interface-specific echo request is what I believe folks are referring to as per-interface. This - in effect - is the primary use for the object in this draft, so any explicit statement to the effect that this is the case would be redundant. While the object includes fields for both an ingress and egress interface, when being used to direct the implementation to respond as if the echo request were directed to a specific interface, only one of these fields would contain valid info. It is possible that both interface numbers are valid. In this case, the object cannot be used for what you are calling a per-interface echo request. However, this case may be useful if - for example - the intention is to verify that the LSP is using this particular interface mapping at this node (i.e. - the request is attempting to ascertain if this is the correct mapping for the LSP). All of this is fairly intuitive to anyone who has read the draft and is reasonably familiar with the technology and protocols involved. This draft is a protocol specification, not a tutorial. As for what may be said in any other draft that is still in the process of being written, that is an issue that is not in scope for this draft. -- Eric -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Yoshinori Koike Sent: Thursday, August 25, 2011 12:35 PM To: ietf@ietf.org Cc: m...@ietf.org; 'IETF-Announce' Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard Hi, I would like to propose that this draft explicitly stipulate whether or not it covers per-interface model. I think it is essential to avoid confusion and clarify the appropriate I-D to discuss OAM solutions for the per-interface model. Per-interface model is one of the two OAM maintenance models in MPLS-TP networks which is specified in section 3 of draft-ietf-mpls-tp-oam-framework. The solution for the per-interface model is under discussion also in the per-interface MIP draft ( http://tools.ietf.org/html/draft-farrel-mpls-tp-mip-mep-map-04 ). If the on-demand-cv-06 covers the OAM solution for per-interface model, the discussion for on-demand CV and route tracing must be removed from the mip-mep-map draft. Otherwise, the mip-mep-map draft has to cover the solutions for on-demand CV and route tracing. I also think that it is important to clarify the comments from Mr. Zhenlong Cui in the draft, whose email is attached at the bottom. It is important to make clear for what purpose the IF_Num is used. It also seems important to clarify the responder's behavior, because the ambiguity will definitely lead to interoperability issues. Thank you in advance. Best regards, Yoshinori Koike (2011/08/25 15:17), Zhenlong Cui wrote: Hi, I have sent some questions regarding the IF_Num of DSMAP TLV before. I'd like to make sure it is not lost. 2.1. New address type for Downstream Mapping TLV The new address type indicates that no address is present in the DSMAP or DDMAP TLV. However, IF_Num information (see definition of IF_NUM in [I-D.ietf-mpls-tp-identifiers]) for both ingress and egress interfaces, as well as multipath information is included in the format and MAY be present. I believe the IF_Num can be used for per-interface MIP model. But I'm not sure why we need use both ingress IF_Num and egress IF_Num in a DSMAP TLV. I can't find this case (Ingress_IF::Egress_IF) in [I-D.ietf-mpls-tp-identifiers]. e.g.) the following are defined in [I-D.ietf-mpls-tp-identifiers] using IF_Num, but there is no Ingress_IF::Egress_IF. - IF_ID IF_ID is a 64-bit identifier formed as Node_ID::IF_Num. - MIP ID For a MIP which is associated with particular interface, we simply use the IF_ID (see Section 4) of the interfaces which are cross- connected. If have any special means in the IF_Num, I think MUST mention it clearly. Also I feeling that this draft have to clarify the responder's behavior for each IF information of the IF_Num. Best regards, zhenlong -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The IESG Sent: Thursday, August 11, 2011 10:46 PM To: IETF-Announce Cc: m...@ietf.org Subject: [mpls] Last Call:draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS On-demand Connectivity Verification and Route Tracing' draft-ietf
Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Sasha, On your final comment on the concept of an MPLS-TP PW, RFC5586 has already made the distinction between the use of the GAL on PWs in MPLS-TP and in other MPLS environments. This draft aligns the two cases in terms of the applicability of the GAL, by updating RFC5586 to remove the restriction on its use and position in an MPLS-TP environment. The case of interconnecting PW segments on MPLS-TP to PW segments on general MPLS networks should be discussed elsewhere, IMHO, as the interaction between the GAL and hashing on some PW segments is most likely not the only issue. RFC5921 rules out the use of ECMP in MPLS-TP networks, so one would not expect an MPLS-TP PSN to hash the flow label today. If that is going to change or if there are other flow label applications in MPLS-TP, then IMHO drafts detailing those applications should discuss the interaction with the GAL. Regards, Matthew On 02/09/2011 06:05, Alexander Vainshtein alexander.vainsht...@ecitele.commailto:alexander.vainsht...@ecitele.com wrote: Stewart, Lots of thanks for a prompt response. My original email contained a typo (S-PE instead of T-PE named as inserting ) which I've acknowledged and corrected in this thread (please see http://www.ietf.org/mail-archive/web/pwe3/current/msg12586.html). With this correction in mind, the example I've presented (an MS-PW that originates in a T-PE in a MPLS-TP domain and them crosses - at S-PE - into an IP/MPLS domain) matches, IMHO, Yaakov's question. And if the operator wishes to improve traffic distribution in the IP/MPLS domain which employs ECMP, flow labels would be inserted by T-PE. I believe that the change in draft-ietf-pwe3-gal-in-pw that you've proposed inhttp://www.ietf.org/mail-archive/web/pwe3/current/msg12613.html resolves the original issue I've raised of both GAL and flow label competing for the BoS position. However, a conceptual question - can any MPLS-TP restrictions be placed on PWs?- remains open as noted in Greg's comment (please see http://www.ietf.org/mail-archive/web/pwe3/current/msg12620.html). IMHO and FWIW we should acknowledge the fact (implicitly recognized already in RFC 5920) that there is simply no such thing as a MPLS-TP PW. Hopefully this note clarifies my position on the subject. Regards, and apologies for the original typo, Sasha From: Stewart Bryant [stbry...@cisco.commailto:stbry...@cisco.com] Sent: Thursday, September 01, 2011 8:33 PM To: Alexander Vainshtein Cc: Yaakov Stein; m...@ietf.orgmailto:m...@ietf.org; pwe3; i...@ietf.orgmailto:i...@ietf.org; pwe3-cha...@tools.ietf.orgmailto:pwe3-cha...@tools.ietf.org; Luca Martini; IETF Discussion Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw On 01/09/2011 17:07, Alexander Vainshtein wrote: Yaakov, You've written PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain This is exactly the point that I've raised in my IETF LC comment on the draft (for MS-PW) - please see my email (to several lists) that explains that in some detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html. Regards, Sasha The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertion and discard of flow labels at the two S-PEs. Speaking as an author of the FAT-PW draft I do not recall any text that proposes that S-PEs insert FLs in the stack, and it never occurred to me that anyone anyone would try, since would require a change to the design of the S-PEs. Stewart 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] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Stewart, Lots of thanks for a prompt response. My original email contained a typo (S-PE instead of T-PE named as inserting ) which I've acknowledged and corrected in this thread (please see http://www.ietf.org/mail-archive/web/pwe3/current/msg12586.html). With this correction in mind, the example I've presented (an MS-PW that originates in a T-PE in a MPLS-TP domain and them crosses - at S-PE - into an IP/MPLS domain) matches, IMHO, Yaakov's question. And if the operator wishes to improve traffic distribution in the IP/MPLS domain which employs ECMP, flow labels would be inserted by T-PE. I believe that the change in draft-ietf-pwe3-gal-in-pw that you've proposed in http://www.ietf.org/mail-archive/web/pwe3/current/msg12613.html resolves the original issue I've raised of both GAL and flow label competing for the BoS position. However, a conceptual question - can any MPLS-TP restrictions be placed on PWs?- remains open as noted in Greg's comment (please see http://www.ietf.org/mail-archive/web/pwe3/current/msg12620.html). IMHO and FWIW we should acknowledge the fact (implicitly recognized already in RFC 5920) that there is simply no such thing as a MPLS-TP PW. Hopefully this note clarifies my position on the subject. Regards, and apologies for the original typo, Sasha From: Stewart Bryant [stbry...@cisco.com] Sent: Thursday, September 01, 2011 8:33 PM To: Alexander Vainshtein Cc: Yaakov Stein; m...@ietf.org; pwe3; i...@ietf.org; pwe3-cha...@tools.ietf.org; Luca Martini; IETF Discussion Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw On 01/09/2011 17:07, Alexander Vainshtein wrote: Yaakov, You've written PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain This is exactly the point that I've raised in my IETF LC comment on the draft (for MS-PW) - please see my email (to several lists) that explains that in some detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html. Regards, Sasha The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertion and discard of flow labels at the two S-PEs. Speaking as an author of the FAT-PW draft I do not recall any text that proposes that S-PEs insert FLs in the stack, and it never occurred to me that anyone anyone would try, since would require a change to the design of the S-PEs. Stewart 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] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Matthew, Lots of thanks for a prompt response. Please see a couple of comments inline below. Regards, Sasha From: Bocci, Matthew (Matthew) [matthew.bo...@alcatel-lucent.com] Sent: Friday, September 02, 2011 1:06 PM To: Alexander Vainshtein; Stewart Bryant Cc: Yaakov Stein; m...@ietf.org; pwe3; i...@ietf.org; pwe3-cha...@tools.ietf.org; Luca Martini; IETF Discussion Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Sasha, On your final comment on the concept of an MPLS-TP PW, RFC5586 has already made the distinction between the use of the GAL on PWs in MPLS-TP and in other MPLS environments. This draft aligns the two cases in terms of the applicability of the GAL, by updating RFC5586 to remove the restriction on its use and position in an MPLS-TP environment. [[Sasha]] IMHO and FWIW this is one more indication that there is no such thing as an MPLS-TP PW as different from an MPLS TP. Did I miss something important? The case of interconnecting PW segments on MPLS-TP to PW segments on general MPLS networks should be discussed elsewhere, IMHO, as the interaction between the GAL and hashing on some PW segments is most likely not the only issue. [[Sasha]] Sounds OK with me. RFC5921 rules out the use of ECMP in MPLS-TP networks, so one would not expect an MPLS-TP PSN to hash the flow label today. [[Sasha]] I make a distinction between inserting a flow label at T-PE and hashing on the label stack (or lack thereof) in some of the network domains that are crossed by the MS-PW packet. The hashing is done (or not done) by P routers that do not specifically care about PWs. If that is going to change or if there are other flow label applications in MPLS-TP, then IMHO drafts detailing those applications should discuss the interaction with the GAL. [[Sasha]] Please see above. IMHO there is no need for a new application to study the interaction. Regards, Matthew On 02/09/2011 06:05, Alexander Vainshtein alexander.vainsht...@ecitele.commailto:alexander.vainsht...@ecitele.com wrote: Stewart, Lots of thanks for a prompt response. My original email contained a typo (S-PE instead of T-PE named as inserting ) which I've acknowledged and corrected in this thread (please see http://www.ietf.org/mail-archive/web/pwe3/current/msg12586.html). With this correction in mind, the example I've presented (an MS-PW that originates in a T-PE in a MPLS-TP domain and them crosses - at S-PE - into an IP/MPLS domain) matches, IMHO, Yaakov's question. And if the operator wishes to improve traffic distribution in the IP/MPLS domain which employs ECMP, flow labels would be inserted by T-PE. I believe that the change in draft-ietf-pwe3-gal-in-pw that you've proposed inhttp://www.ietf.org/mail-archive/web/pwe3/current/msg12613.html resolves the original issue I've raised of both GAL and flow label competing for the BoS position. However, a conceptual question - can any MPLS-TP restrictions be placed on PWs?- remains open as noted in Greg's comment (please see http://www.ietf.org/mail-archive/web/pwe3/current/msg12620.html). IMHO and FWIW we should acknowledge the fact (implicitly recognized already in RFC 5920) that there is simply no such thing as a MPLS-TP PW. Hopefully this note clarifies my position on the subject. Regards, and apologies for the original typo, Sasha From: Stewart Bryant [stbry...@cisco.commailto:stbry...@cisco.com] Sent: Thursday, September 01, 2011 8:33 PM To: Alexander Vainshtein Cc: Yaakov Stein; m...@ietf.orgmailto:m...@ietf.org; pwe3; i...@ietf.orgmailto:i...@ietf.org; pwe3-cha...@tools.ietf.orgmailto:pwe3-cha...@tools.ietf.org; Luca Martini; IETF Discussion Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw On 01/09/2011 17:07, Alexander Vainshtein wrote: Yaakov, You've written PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain This is exactly the point that I've raised in my IETF LC comment on the draft (for MS-PW) - please see my email (to several lists) that explains that in some detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html. Regards, Sasha The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertion and discard of flow labels at the two S-PEs. Speaking as an author of the FAT-PW draft I do not recall any text that proposes that S-PEs insert FLs in the stack, and it never occurred to me that anyone anyone would try, since would require a change to the design of the S-PEs. Stewart 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. This e-mail message is intended for the recipient only
RE: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Yaakov, You've written PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain This is exactly the point that I've raised in my IETF LC comment on the draft (for MS-PW) - please see my email (to several lists) that explains that in some detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html. Regards, Sasha From: mpls-boun...@ietf.org [mpls-boun...@ietf.org] On Behalf Of Yaakov Stein [yaako...@rad.com] Sent: Thursday, September 01, 2011 5:37 PM To: stbry...@cisco.com; Luca Martini; IETF Discussion Cc: m...@ietf.org; pwe3; i...@ietf.org; pwe3-cha...@tools.ietf.org Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Stewart Was this email meant to address my email to the IETF discussion list (from Tues 16 Aug) or just the discussion on MPLS and PWE lists ? It does to SOME extent, as it leaves open the possibility of the GAL not being at BoS; but it does not rule out that possibility either. However, you did not address my other final comment that a PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain. What does one do then ? (My email also identified a wording issue and what I consider to be a completely inaccurate explanation of what the draft is trying to accomplish.) Y(J)S From: pwe3-boun...@ietf.org [mailto:pwe3-boun...@ietf.org] On Behalf Of Stewart Bryant Sent: Tuesday, August 30, 2011 15:05 To: Luca Martini; IETF Discussion Cc: ietf@ietf.org; Vladimir Kleiner; m...@ietf.org; Idan Kaspit; Mishael Wexler; pwe3; i...@ietf.org; Oren Gal; John Shirron; pwe3-cha...@tools.ietf.org; Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Reviewing this discussion there are three components. 1) The update of RFC5586 to allow PW to use the GAL. 2) The PW OAM application that is to use the GAL. 3) The label stack structure when teh GAL is used with a PW This draft is only concerned with point 1 above. Points 2 and 3 need to be resolved in any PWE3 draft that describes the use of the GAL. To that end the text in draft-ietf-pwe3-mpls-tp-gal-in-pw-01 - Section 4.2http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01#section-4.2. (GAL Applicability and Usage) in [RFC5586http://tools.ietf.org/html/rfc5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack. = should be replaced by = - Section 4.2http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01#section-4.2. (GAL Applicability and Usage) in [RFC5586http://tools.ietf.org/html/rfc5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. The presence of a GAL indicates that an ACH immediately follows the MPLS label stack. == - Stewart 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] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Dear Yaakov and Sasha, I share your concern in regard to MPLS-TP-ness of MS-PW construct. It was in my background thinking when I was querying Sasha and I think that the chimera is quite proper characterization for MS-PW in MPLS-TP. Regards, Greg On Thu, Sep 1, 2011 at 9:07 AM, Alexander Vainshtein alexander.vainsht...@ecitele.com wrote: Yaakov, You've written PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain This is exactly the point that I've raised in my IETF LC comment on the draft (for MS-PW) - please see my email (to several lists) that explains that in some detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html. Regards, Sasha From: mpls-boun...@ietf.org [mpls-boun...@ietf.org] On Behalf Of Yaakov Stein [yaako...@rad.com] Sent: Thursday, September 01, 2011 5:37 PM To: stbry...@cisco.com; Luca Martini; IETF Discussion Cc: m...@ietf.org; pwe3; i...@ietf.org; pwe3-cha...@tools.ietf.org Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Stewart Was this email meant to address my email to the IETF discussion list (from Tues 16 Aug) or just the discussion on MPLS and PWE lists ? It does to SOME extent, as it leaves open the possibility of the GAL not being at BoS; but it does not rule out that possibility either. However, you did not address my other final comment that a PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain. What does one do then ? (My email also identified a wording issue and what I consider to be a completely inaccurate explanation of what the draft is trying to accomplish.) Y(J)S From: pwe3-boun...@ietf.org [mailto:pwe3-boun...@ietf.org] On Behalf Of Stewart Bryant Sent: Tuesday, August 30, 2011 15:05 To: Luca Martini; IETF Discussion Cc: ietf@ietf.org; Vladimir Kleiner; m...@ietf.org; Idan Kaspit; Mishael Wexler; pwe3; i...@ietf.org; Oren Gal; John Shirron; pwe3-cha...@tools.ietf.org; Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Reviewing this discussion there are three components. 1) The update of RFC5586 to allow PW to use the GAL. 2) The PW OAM application that is to use the GAL. 3) The label stack structure when teh GAL is used with a PW This draft is only concerned with point 1 above. Points 2 and 3 need to be resolved in any PWE3 draft that describes the use of the GAL. To that end the text in draft-ietf-pwe3-mpls-tp-gal-in-pw-01 - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack. = should be replaced by = - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. The presence of a GAL indicates that an ACH immediately follows the MPLS label stack. == - Stewart 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. ___ 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] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
On 01/09/2011 17:07, Alexander Vainshtein wrote: Yaakov, You've written PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain This is exactly the point that I've raised in my IETF LC comment on the draft (for MS-PW) - please see my email (to several lists) that explains that in some detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html. Regards, Sasha The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertionand discard of flow labels at the two S-PEs. Speaking as an author of the FAT-PW draft I do not recall any text that proposes that S-PEs insert FLs in the stack, and it never occurred to me that anyone anyone would try, since would require a change to the design of the S-PEs. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Reviewing this discussion there are three components. 1) The update of RFC5586 to allow PW to use the GAL. 2) The PW OAM application that is to use the GAL. 3) The label stack structure when teh GAL is used with a PW This draft is only concerned with point 1 above. Points 2 and 3 need to be resolved in any PWE3 draft that describes the use of the GAL. To that end the text in draft-ietf-pwe3-mpls-tp-gal-in-pw-01 -Section 4.2 http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01#section-4.2. (GAL Applicability and Usage) in [RFC5586 http://tools.ietf.org/html/rfc5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack. = should be replaced by = -Section 4.2 http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01#section-4.2. (GAL Applicability and Usage) in [RFC5586 http://tools.ietf.org/html/rfc5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. The presence of a GAL indicates that an ACH immediately follows the MPLS label stack. == - Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Stewart, I believe that your item #1 is presumably addressed by draft-ietf-pwe3-gal-in-pw (with the changes you've proposed), draft-nadeau-pwe3-vccv-2 is an attempt to address your item #2, and your item #3 is not yet addressed. Is this understanding correct? I also think that one of the items in the discussion was the restriction on ECMP in MPLS to skip reserved labels. I am not sure if it has been properly addressed anywhere, so should not it constitute item #4? Regards, Sasha From: Stewart Bryant [mailto:stbry...@cisco.com] Sent: Tuesday, August 30, 2011 3:05 PM To: Luca Martini; IETF Discussion Cc: John E Drake; m...@ietf.org; Alexander Vainshtein; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; pwe3-cha...@tools.ietf.org; i...@ietf.org Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Reviewing this discussion there are three components. 1) The update of RFC5586 to allow PW to use the GAL. 2) The PW OAM application that is to use the GAL. 3) The label stack structure when teh GAL is used with a PW This draft is only concerned with point 1 above. Points 2 and 3 need to be resolved in any PWE3 draft that describes the use of the GAL. To that end the text in draft-ietf-pwe3-mpls-tp-gal-in-pw-01 - Section 4.2http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01#section-4.2. (GAL Applicability and Usage) in [RFC5586http://tools.ietf.org/html/rfc5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack. = should be replaced by = - Section 4.2http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01#section-4.2. (GAL Applicability and Usage) in [RFC5586http://tools.ietf.org/html/rfc5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. The presence of a GAL indicates that an ACH immediately follows the MPLS label stack. == - Stewart 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] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Sasha On 30/08/2011 13:22, Alexander Vainshtein wrote: Stewart, I believe that your item #1 is presumably addressed by draft-ietf-pwe3-gal-in-pw (with the changes you’ve proposed), draft-nadeau-pwe3-vccv-2 is an attempt to address your item #2, and your item #3 is not yet addressed. Is this understanding correct? Yes I also think that one of the items in the discussion was the restriction on ECMP in MPLS to skip reserved labels. I am not sure if it has been properly addressed anywhere, so should not it constitute item #4? Yes-ish, here I am concerned about the practical ability to do that given the extent of deployed LSRs that do not do that. My point here was to note the scope of this draft (which is is IESG review). Other drafts need to make their own case for what they want to do and how they propose to do it. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard
Hi, I would like to propose that this draft explicitly stipulate whether or not it covers per-interface model. I think it is essential to avoid confusion and clarify the appropriate I-D to discuss OAM solutions for the per-interface model. Per-interface model is one of the two OAM maintenance models in MPLS-TP networks which is specified in section 3 of draft-ietf-mpls-tp-oam-framework. The solution for the per-interface model is under discussion also in the per-interface MIP draft ( http://tools.ietf.org/html/draft-farrel-mpls-tp-mip-mep-map-04 ). If the on-demand-cv-06 covers the OAM solution for per-interface model, the discussion for on-demand CV and route tracing must be removed from the mip-mep-map draft. Otherwise, the mip-mep-map draft has to cover the solutions for on-demand CV and route tracing. I also think that it is important to clarify the comments from Mr. Zhenlong Cui in the draft, whose email is attached at the bottom. It is important to make clear for what purpose the IF_Num is used. It also seems important to clarify the responder's behavior, because the ambiguity will definitely lead to interoperability issues. Thank you in advance. Best regards, Yoshinori Koike (2011/08/25 15:17), Zhenlong Cui wrote: Hi, I have sent some questions regarding the IF_Num of DSMAP TLV before. I'd like to make sure it is not lost. 2.1. New address type for Downstream Mapping TLV The new address type indicates that no address is present in the DSMAP or DDMAP TLV. However, IF_Num information (see definition of IF_NUM in [I-D.ietf-mpls-tp-identifiers]) for both ingress and egress interfaces, as well as multipath information is included in the format and MAY be present. I believe the IF_Num can be used for per-interface MIP model. But I'm not sure why we need use both ingress IF_Num and egress IF_Num in a DSMAP TLV. I can't find this case (Ingress_IF::Egress_IF) in [I-D.ietf-mpls-tp-identifiers]. e.g.) the following are defined in [I-D.ietf-mpls-tp-identifiers] using IF_Num, but there is no Ingress_IF::Egress_IF. - IF_ID IF_ID is a 64-bit identifier formed as Node_ID::IF_Num. - MIP ID For a MIP which is associated with particular interface, we simply use the IF_ID (see Section 4) of the interfaces which are cross- connected. If have any special means in the IF_Num, I think MUST mention it clearly. Also I feeling that this draft have to clarify the responder's behavior for each IF information of the IF_Num. Best regards, zhenlong -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The IESG Sent: Thursday, August 11, 2011 10:46 PM To: IETF-Announce Cc: m...@ietf.org Subject: [mpls] Last Call:draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS On-demand Connectivity Verification and Route Tracing' draft-ietf-mpls-tp-on-demand-cv-06.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-08-25. 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 Label Switched Path Ping (LSP-Ping) is an existing and widely deployed Operations, Administration and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP-Ping so that LSP- Ping can be used for On-demand Connectivity Verification of MPLS Transport Profile (MPLS-TP) LSPs and Pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP-Ping to perform Connectivity Verification and Route Tracing functions in MPLS-TP networks. Finally this document updates RFC 4379 by adding a new address type and requesting an IANA registry. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ No IPR declarations have been submitted directly on this I-D. ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard
Hi, I have sent some questions regarding the IF_Num of DSMAP TLV before. I'd like to make sure it is not lost. 2.1. New address type for Downstream Mapping TLV The new address type indicates that no address is present in the DSMAP or DDMAP TLV. However, IF_Num information (see definition of IF_NUM in [I-D.ietf-mpls-tp-identifiers]) for both ingress and egress interfaces, as well as multipath information is included in the format and MAY be present. I believe the IF_Num can be used for per-interface MIP model. But I'm not sure why we need use both ingress IF_Num and egress IF_Num in a DSMAP TLV. I can't find this case (Ingress_IF::Egress_IF) in [I-D.ietf-mpls-tp-identifiers]. e.g.) the following are defined in [I-D.ietf-mpls-tp-identifiers] using IF_Num, but there is no Ingress_IF::Egress_IF. - IF_ID IF_ID is a 64-bit identifier formed as Node_ID::IF_Num. - MIP ID For a MIP which is associated with particular interface, we simply use the IF_ID (see Section 4) of the interfaces which are cross- connected. If have any special means in the IF_Num, I think MUST mention it clearly. Also I feeling that this draft have to clarify the responder's behavior for each IF information of the IF_Num. Best regards, zhenlong -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The IESG Sent: Thursday, August 11, 2011 10:46 PM To: IETF-Announce Cc: m...@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS On-demand Connectivity Verification and Route Tracing' draft-ietf-mpls-tp-on-demand-cv-06.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-08-25. 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 Label Switched Path Ping (LSP-Ping) is an existing and widely deployed Operations, Administration and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP-Ping so that LSP- Ping can be used for On-demand Connectivity Verification of MPLS Transport Profile (MPLS-TP) LSPs and Pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP-Ping to perform Connectivity Verification and Route Tracing functions in MPLS-TP networks. Finally this document updates RFC 4379 by adding a new address type and requesting an IANA registry. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ 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] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
John, I would like to let applications decide how they design the use of the gal. So I would propose a simple change , that will move any discussions to the specific applications: The next text would be as follows: - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. Does this work ? Thanks. Luca On 08/18/11 08:00, John E Drake wrote: Sasha, I completely agree with your recommendations: - releasing the bottom-of-stack requirement on GAL - making use of the statement in RFC 5586 that if GAL is encountered in a packet then G-ACh header MUST be present immediately after the bottom of the label stack (and not immediately after GAL) - specifying that ECMP on labeled packets MUST ignore reserved labels Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, August 17, 2011 9:52 PM To: Luca Martini Cc: m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3- gal-in-pw Luca and all, I have not found the statement you've proposed in draft-ietf-pwe3-fat- pw-06. Instead, it contans the following text in Section 8.5 Applicability to MPLS-TP: quote The flow aware transport of a PW reorders packets, therefore MUST NOT be deployed in a network conforming to the MPLS-TP unless these integrity requirements specified in the SLA can be satisfied. end quote (In the -07 version this text is repeated but followed by an incomplete statement In a immediately followed by the heading of Section 8.6. Since this addition is difficult to parse, I will ignore it for the moment.) IMHO and FWIW this means that prohibition on using flow aware PW in MPLS-TP environments is conditional on meeting specific SLA requirements for the service. So I think that the use case I've presented still holds. Please note also that, regardless of the restriction in draft-ietf- pwe3-fat-pw, be it conditional or absolute, usage of flow labels in an MPLS-TP domain would be perfectly safe if ECMP (i.e., hashing of the label stack and taking one of multiple NHLFEs for the given incoming label in the ILM) were not used in this domain, e.g., by associating exactly one ILM entry with each incoming label in the ILM. And since MPLS-TP is supposed to carry not just PW clients but also IP ones, I would expect that this would be the case in any MPLS-TP deployment. I also think that releasing one restriction (on using GAL in PWs) at the expense of making another, conditional one (on usage of flow labels in MPLS-TP environments) absolute is not the most appropriate method for resolving technical issues. IMHO and FWIW better way to resolve the problem would be by: - releasing the bottom-of-stack requirement on GAL - making use of the statement in RFC 5586 that if GAL is encountered in a packet then G-ACh header MUST be present immediately after the bottom of the label stack (and not immediately after GAL) - specifying that ECMP on labeled packets MUST ignore reserved labels. I think that these considerations have been presented already in the discussion on draft-nadeau-pwe-vccv-2. Of course it would be even better if we could agree on transition to universal usage of the CW and VCCV Type 1 in PWs. But this is a different story. Regards, Sasha From: Luca Martini [lmart...@cisco.com] Sent: Wednesday, August 17, 2011 9:58 PM To: Alexander Vainshtein Cc: Pablo Frank; m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw The solution is quite simple: Flow Labels MUST not be used in an MPLS-TP environment. Luca On 08/16/11 21:46, Alexander Vainshtein wrote: Pablo, Sorry, but I think you're wrong. Only T-PE can insert the flow label (because only T=PE can be flow-aware). S-PE simply performs swap on PW label. Regards, Sasha - --- *From:* Pablo Frank [pablois...@gmail.com] *Sent:* Wednesday, August 17, 2011 12
RE: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Luca, So, you are considering weighted ECMP, with FAT and entropy label, to be an application? We are also releasing the GAL to float until it finds its proper level within the MPLS label stack? Thanks, John Sent from my iPhone -Original Message- From: Luca Martini [mailto:lmart...@cisco.com] Sent: Friday, August 19, 2011 1:17 PM To: John E Drake Cc: Alexander Vainshtein; m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3- gal-in-pw John, I would like to let applications decide how they design the use of the gal. So I would propose a simple change , that will move any discussions to the specific applications: The next text would be as follows: - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. Does this work ? Thanks. Luca On 08/18/11 08:00, John E Drake wrote: Sasha, I completely agree with your recommendations: - releasing the bottom-of-stack requirement on GAL - making use of the statement in RFC 5586 that if GAL is encountered in a packet then G-ACh header MUST be present immediately after the bottom of the label stack (and not immediately after GAL) - specifying that ECMP on labeled packets MUST ignore reserved labels Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, August 17, 2011 9:52 PM To: Luca Martini Cc: m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf- pwe3- gal-in-pw Luca and all, I have not found the statement you've proposed in draft-ietf-pwe3- fat- pw-06. Instead, it contans the following text in Section 8.5 Applicability to MPLS-TP: quote The flow aware transport of a PW reorders packets, therefore MUST NOT be deployed in a network conforming to the MPLS-TP unless these integrity requirements specified in the SLA can be satisfied. end quote (In the -07 version this text is repeated but followed by an incomplete statement In a immediately followed by the heading of Section 8.6. Since this addition is difficult to parse, I will ignore it for the moment.) IMHO and FWIW this means that prohibition on using flow aware PW in MPLS-TP environments is conditional on meeting specific SLA requirements for the service. So I think that the use case I've presented still holds. Please note also that, regardless of the restriction in draft-ietf- pwe3-fat-pw, be it conditional or absolute, usage of flow labels in an MPLS-TP domain would be perfectly safe if ECMP (i.e., hashing of the label stack and taking one of multiple NHLFEs for the given incoming label in the ILM) were not used in this domain, e.g., by associating exactly one ILM entry with each incoming label in the ILM. And since MPLS-TP is supposed to carry not just PW clients but also IP ones, I would expect that this would be the case in any MPLS-TP deployment. I also think that releasing one restriction (on using GAL in PWs) at the expense of making another, conditional one (on usage of flow labels in MPLS-TP environments) absolute is not the most appropriate method for resolving technical issues. IMHO and FWIW better way to resolve the problem would be by: - releasing the bottom-of-stack requirement on GAL - making use of the statement in RFC 5586 that if GAL is encountered in a packet then G-ACh header MUST be present immediately after the bottom of the label stack (and not immediately after GAL) - specifying that ECMP on labeled packets MUST ignore reserved labels. I think that these considerations have been presented already in the discussion on draft-nadeau-pwe-vccv-2. Of course it would be even better if we could agree on transition to universal usage of the CW and VCCV Type 1 in PWs. But this is a different story. Regards, Sasha From: Luca Martini [lmart...@cisco.com] Sent: Wednesday, August 17, 2011 9:58 PM
Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
On 08/19/11 14:53, John E Drake wrote: Luca, So, you are considering weighted ECMP, with FAT and entropy label, to be an application? We are also releasing the GAL to float until it finds its proper level within the MPLS label stack? Yes. It certainly addresses a specific problem that is only a concern in some networks. Maybe as application I meant the specific technology documents. For example if an OAM method needs to use the GAL for a specific purpose it should specify it there, without us putting restrictions in a generic way in this document. As for the float part, I consider the GAL to be a simple Flag that says following the MPLS label stack , you will find a GACh construct , and not an IP packet In MPLS the default is to have an IP packet, unless a different meaning is bound to the label by the control plane. Thsi is the reason we needed the GAL in the first place for the MPLS-TP environment , where IP is not used. Thanks, Luca Thanks, John Sent from my iPhone -Original Message- From: Luca Martini [mailto:lmart...@cisco.com] Sent: Friday, August 19, 2011 1:17 PM To: John E Drake Cc: Alexander Vainshtein; m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3- gal-in-pw John, I would like to let applications decide how they design the use of the gal. So I would propose a simple change , that will move any discussions to the specific applications: The next text would be as follows: - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. Does this work ? Thanks. Luca On 08/18/11 08:00, John E Drake wrote: Sasha, I completely agree with your recommendations: - releasing the bottom-of-stack requirement on GAL - making use of the statement in RFC 5586 that if GAL is encountered in a packet then G-ACh header MUST be present immediately after the bottom of the label stack (and not immediately after GAL) - specifying that ECMP on labeled packets MUST ignore reserved labels Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, August 17, 2011 9:52 PM To: Luca Martini Cc: m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf- pwe3- gal-in-pw Luca and all, I have not found the statement you've proposed in draft-ietf-pwe3- fat- pw-06. Instead, it contans the following text in Section 8.5 Applicability to MPLS-TP: quote The flow aware transport of a PW reorders packets, therefore MUST NOT be deployed in a network conforming to the MPLS-TP unless these integrity requirements specified in the SLA can be satisfied. end quote (In the -07 version this text is repeated but followed by an incomplete statement In a immediately followed by the heading of Section 8.6. Since this addition is difficult to parse, I will ignore it for the moment.) IMHO and FWIW this means that prohibition on using flow aware PW in MPLS-TP environments is conditional on meeting specific SLA requirements for the service. So I think that the use case I've presented still holds. Please note also that, regardless of the restriction in draft-ietf- pwe3-fat-pw, be it conditional or absolute, usage of flow labels in an MPLS-TP domain would be perfectly safe if ECMP (i.e., hashing of the label stack and taking one of multiple NHLFEs for the given incoming label in the ILM) were not used in this domain, e.g., by associating exactly one ILM entry with each incoming label in the ILM. And since MPLS-TP is supposed to carry not just PW clients but also IP ones, I would expect that this would be the case in any MPLS-TP deployment. I also think that releasing one restriction (on using GAL in PWs) at the expense of making another, conditional one (on usage of flow labels in MPLS-TP environments) absolute is not the most appropriate method for resolving technical issues. IMHO and FWIW better way to resolve the problem would be by: - releasing the bottom-of-stack requirement on GAL
Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
On Aug 19, 2011, at 5:09 PM, Luca Martini wrote: On 08/19/11 14:53, John E Drake wrote: Luca, So, you are considering weighted ECMP, with FAT and entropy label, to be an application? We are also releasing the GAL to float until it finds its proper level within the MPLS label stack? Yes. It certainly addresses a specific problem that is only a concern in some networks. Maybe as application I meant the specific technology documents. For example if an OAM method needs to use the GAL for a specific purpose it should specify it there, without us putting restrictions in a generic way in this document. As for the float part, I consider the GAL to be a simple Flag that says following the MPLS label stack , you will find a GACh construct , and not an IP packet This makes a lot of sense to me as it makes sure that the specific applications use the GAL as needed. This document should just lay out the generic rules for using it, but not preclude its use by some application we have not through of yet down the road by making rules that are too narrow. --Tom In MPLS the default is to have an IP packet, unless a different meaning is bound to the label by the control plane. Thsi is the reason we needed the GAL in the first place for the MPLS-TP environment , where IP is not used. Thanks, Luca Thanks, John Sent from my iPhone -Original Message- From: Luca Martini [mailto:lmart...@cisco.com] Sent: Friday, August 19, 2011 1:17 PM To: John E Drake Cc: Alexander Vainshtein; m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3- gal-in-pw John, I would like to let applications decide how they design the use of the gal. So I would propose a simple change , that will move any discussions to the specific applications: The next text would be as follows: - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. Does this work ? Thanks. Luca On 08/18/11 08:00, John E Drake wrote: Sasha, I completely agree with your recommendations: - releasing the bottom-of-stack requirement on GAL - making use of the statement in RFC 5586 that if GAL is encountered in a packet then G-ACh header MUST be present immediately after the bottom of the label stack (and not immediately after GAL) - specifying that ECMP on labeled packets MUST ignore reserved labels Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, August 17, 2011 9:52 PM To: Luca Martini Cc: m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf- pwe3- gal-in-pw Luca and all, I have not found the statement you've proposed in draft-ietf-pwe3- fat- pw-06. Instead, it contans the following text in Section 8.5 Applicability to MPLS-TP: quote The flow aware transport of a PW reorders packets, therefore MUST NOT be deployed in a network conforming to the MPLS-TP unless these integrity requirements specified in the SLA can be satisfied. end quote (In the -07 version this text is repeated but followed by an incomplete statement In a immediately followed by the heading of Section 8.6. Since this addition is difficult to parse, I will ignore it for the moment.) IMHO and FWIW this means that prohibition on using flow aware PW in MPLS-TP environments is conditional on meeting specific SLA requirements for the service. So I think that the use case I've presented still holds. Please note also that, regardless of the restriction in draft-ietf- pwe3-fat-pw, be it conditional or absolute, usage of flow labels in an MPLS-TP domain would be perfectly safe if ECMP (i.e., hashing of the label stack and taking one of multiple NHLFEs for the given incoming label in the ILM) were not used in this domain, e.g., by associating exactly one ILM entry with each incoming label in the ILM. And since MPLS-TP is supposed to carry not just PW clients but also IP ones, I would expect
Re: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLS On-demand Connectivity Verification and Route Tracing) to Proposed Standard
Hi,
I don't see any TLVs defined for performing the on-demand CV operation
on MPLS -TP Sections. Is this intentional?
and
Co-routed bidirectional tunnel identifier:
A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::
Node_ID::Tunnel_Num}::LSP_Num
Associated bidirectional tunnel identifier:
A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}::
Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}
How does Static LSP Sub-TLV address the need of two LSP_Nums of
associated bidirectional tunnel?
Am I missing something?
Thanks,
Venkat.
On Fri, Aug 19, 2011 at 5:50 AM, Mach Chen mach.c...@huawei.com wrote:
Hi,
One question about the difference of the encapsulation modes between CV and
Route Tracing.
In Section 3, there are three encapsulation modes for on-demand CV: LSP-Ping
with IP encapsulation, On-demand CV with IP encapsulation, over ACH and
Non-IP based On-demand CV, using ACH, but for On-demand Route Tracing (in
section 4), there are only two modes: On-demand LSP Route Tracing with IP
encapsulation and Non-IP based On-demand LSP Route Tracing, using ACH.
Seems that there should be On-demand LSP Route Tracing with IP
encapsulation, over ACH accordingly. What's reason behind this? Or maybe I
missed something.
Best regards,
Mach
-Original Message-
From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The
IESG
Sent: Thursday, August 11, 2011 9:46 PM
To: IETF-Announce
Cc: m...@ietf.org
Subject: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLS
On-demand Connectivity Verification and Route Tracing) to Proposed Standard
The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'MPLS On-demand Connectivity Verification and Route Tracing'
draft-ietf-mpls-tp-on-demand-cv-06.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-08-25. 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
Label Switched Path Ping (LSP-Ping) is an existing and widely
deployed Operations, Administration and Maintenance (OAM) mechanism
for Multi-Protocol Label Switching (MPLS) Label Switched Paths
(LSPs). This document describes extensions to LSP-Ping so that LSP-
Ping can be used for On-demand Connectivity Verification of MPLS
Transport Profile (MPLS-TP) LSPs and Pseudowires. This document also
clarifies procedures to be used for processing the related OAM
packets. Further, it describes procedures for using LSP-Ping to
perform Connectivity Verification and Route Tracing functions in
MPLS-TP networks. Finally this document updates RFC 4379 by adding a
new address type and requesting an IANA registry.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/
No IPR declarations have been submitted directly on this I-D.
___
mpls mailing list
m...@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
___
mpls mailing list
m...@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLS On-demand Connectivity Verification and Route Tracing) to Proposed Standard
Eric,
Don't you feel that uniformity should be maintained on AGI field
representation for on-demand and proactive OAM operations?
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type| AGI Length | AGI Value|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~AGI Value (contd.)~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
draft-ietf-mpls-tp-cc-cv-rdi-06, section 3.5.3. PW Endpoint MEP-ID and
draft-ietf-mpls-tp-on-demand-cv-06, section 2.3.2. Static Pseudowire
Sub-TLV conflict in representing the AGI field.
Why are we not following this generic format for representing the AGI field?
Am I missing something?
Thanks,
Venkat.
Re: [mpls] Need clarification on draft-ietf-mpls-tp-on-demand-cv-05
To: binny jeshan binnyjeshan at gmail.com, mpls at ietf.org mpls
at ietf.org
Subject: Re: [mpls] Need clarification on draft-ietf-mpls-tp-on-demand-cv-05
From: Eric Gray eric.gray at ericsson.com
Date: Thu, 11 Aug 2011 07:03:09 -0400
Accept-language: en-US
Acceptlanguage: en-US
Cc: Ross Callon rcallon at juniper.net, MPLS-TP ad hoc team
ahmpls-tp at lists.itu.int, draft-ietf-mpls-tp-on-demand-cv at
tools.ietf.org draft-ietf-mpls-tp-on-demand-cv at tools.ietf.org
Delivered-to: mpls at ietfa.amsl.com
In-reply-to: CAHcPYOzo1vO_ThspndrZwf-X8JAf2b0Mr1SGp7mL2HfN_OxRNw at
mail.gmail.com
List-archive: http://www.ietf.org/mail-archive/web/mpls
List-help: mailto:mpls-requ...@ietf.org?subject=help
List-id: Multi-Protocol Label Switching WG mpls.ietf.org
List-post: mailto:m...@ietf.org
List-subscribe: https://www.ietf.org/mailman/listinfo/mpls,
mailto:mpls-requ...@ietf.org?subject=subscribe
List-unsubscribe: https://www.ietf.org/mailman/options/mpls,
mailto:mpls-requ...@ietf.org?subject=unsubscribe
References: CAHcPYOzo1vO_ThspndrZwf-X8JAf2b0Mr1SGp7mL2HfN_OxRNw at
mail.gmail.com
Thread-index: AcxAZ8Iuor4OYFULT7mPiL+c0YrKTgXrKqiA
Thread-topic: Need clarification on draft-ietf-mpls-tp-on-demand-cv-05
Binny,
We discussed this in detail. Superficially, this seemed like a great idea,
with precedents in the CC/CV/RDI draft.
The issues we ran into include:
1) the Static PW ID TLV is already a sub-TLV; there are issues and a very
undesirable precedent associated with creating a sub-TLV for a sub-TLV.
2) the flexibility associated with inheriting the type code also poses a risk;
we cannot know in advance what other AGI types might be invented in
the future, and whether or not it would make sense in then existing TP
implementations to support generally the new type(s) as part of the
Static PW Identifier Sub-TLV.
What we decided to do was to change the name of the field to Service
Identifier - which will be an unsigned integer and which may contain a type
0x01 AGI, for example. Because it is an unsigned integer, it may also be
used to contain anything smaller than 64 bits.
The flexibility to support other AGI types still exists, should it become
necessary to do so. In that event, we could define additional Static PW
Sub-TLV type(s) to support any AGI type(s) that make sense at that time.
Thanks for your thoughtful and thought-provoking input! We appreciate
your putting time into reviewing our draft...
--
Eric
On Sun, Aug 21, 2011 at 1:48 PM, venkatesan mahalingam
venkatf...@gmail.com wrote:
Hi,
I don't see any TLVs defined for performing the on-demand CV operation
on MPLS -TP Sections. Is this intentional?
and
Co-routed bidirectional tunnel identifier:
A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::
Node_ID::Tunnel_Num}::LSP_Num
Associated bidirectional tunnel identifier:
A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}::
Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}
How does Static LSP Sub-TLV address the need of two LSP_Nums of
associated bidirectional tunnel?
Am I missing something?
Thanks,
Venkat.
On Fri, Aug 19, 2011 at 5:50 AM, Mach Chen mach.c...@huawei.com wrote:
Hi,
One question about the difference of the encapsulation modes between CV and
Route Tracing.
In Section 3, there are three encapsulation modes for on-demand CV:
LSP-Ping with IP encapsulation, On-demand CV with IP encapsulation, over
ACH and Non-IP based On-demand CV, using ACH, but for On-demand Route
Tracing (in section 4), there are only two modes: On-demand LSP Route
Tracing with IP encapsulation and Non-IP based On-demand LSP Route
Tracing, using ACH. Seems that there should be On-demand LSP Route Tracing
with IP encapsulation, over ACH accordingly. What's reason behind this? Or
maybe I missed something.
Best regards,
Mach
-Original Message-
From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The
IESG
Sent: Thursday, August 11, 2011 9:46 PM
To: IETF-Announce
Cc: m...@ietf.org
Subject: [mpls] Last Call
RE: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLS On-demand Connectivity Verification and Route Tracing) to Proposed Standard
Hi, I have made this comment before, I just want to make sure it is not lost. This draft is proposing a way to specify the length of sub-TLVs that is inconsistent with RFC 4379. I believe it would be better to align this with 4379 as the draft is updating it and I see no technical reason why this should be done differently from 4379. 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 The IESG Sent: Donnerstag, 11. August 2011 15:46 To: IETF-Announce Cc: m...@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLS On-demand Connectivity Verification and Route Tracing) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS On-demand Connectivity Verification and Route Tracing' draft-ietf-mpls-tp-on-demand-cv-06.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-08-25. 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 Label Switched Path Ping (LSP-Ping) is an existing and widely deployed Operations, Administration and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP-Ping so that LSP- Ping can be used for On-demand Connectivity Verification of MPLS Transport Profile (MPLS-TP) LSPs and Pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP-Ping to perform Connectivity Verification and Route Tracing functions in MPLS-TP networks. Finally this document updates RFC 4379 by adding a new address type and requesting an IANA registry. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ 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] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Sasha, I completely agree with your recommendations: - releasing the bottom-of-stack requirement on GAL - making use of the statement in RFC 5586 that if GAL is encountered in a packet then G-ACh header MUST be present immediately after the bottom of the label stack (and not immediately after GAL) - specifying that ECMP on labeled packets MUST ignore reserved labels Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, August 17, 2011 9:52 PM To: Luca Martini Cc: m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3- gal-in-pw Luca and all, I have not found the statement you've proposed in draft-ietf-pwe3-fat- pw-06. Instead, it contans the following text in Section 8.5 Applicability to MPLS-TP: quote The flow aware transport of a PW reorders packets, therefore MUST NOT be deployed in a network conforming to the MPLS-TP unless these integrity requirements specified in the SLA can be satisfied. end quote (In the -07 version this text is repeated but followed by an incomplete statement In a immediately followed by the heading of Section 8.6. Since this addition is difficult to parse, I will ignore it for the moment.) IMHO and FWIW this means that prohibition on using flow aware PW in MPLS-TP environments is conditional on meeting specific SLA requirements for the service. So I think that the use case I've presented still holds. Please note also that, regardless of the restriction in draft-ietf- pwe3-fat-pw, be it conditional or absolute, usage of flow labels in an MPLS-TP domain would be perfectly safe if ECMP (i.e., hashing of the label stack and taking one of multiple NHLFEs for the given incoming label in the ILM) were not used in this domain, e.g., by associating exactly one ILM entry with each incoming label in the ILM. And since MPLS-TP is supposed to carry not just PW clients but also IP ones, I would expect that this would be the case in any MPLS-TP deployment. I also think that releasing one restriction (on using GAL in PWs) at the expense of making another, conditional one (on usage of flow labels in MPLS-TP environments) absolute is not the most appropriate method for resolving technical issues. IMHO and FWIW better way to resolve the problem would be by: - releasing the bottom-of-stack requirement on GAL - making use of the statement in RFC 5586 that if GAL is encountered in a packet then G-ACh header MUST be present immediately after the bottom of the label stack (and not immediately after GAL) - specifying that ECMP on labeled packets MUST ignore reserved labels. I think that these considerations have been presented already in the discussion on draft-nadeau-pwe-vccv-2. Of course it would be even better if we could agree on transition to universal usage of the CW and VCCV Type 1 in PWs. But this is a different story. Regards, Sasha From: Luca Martini [lmart...@cisco.com] Sent: Wednesday, August 17, 2011 9:58 PM To: Alexander Vainshtein Cc: Pablo Frank; m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw The solution is quite simple: Flow Labels MUST not be used in an MPLS-TP environment. Luca On 08/16/11 21:46, Alexander Vainshtein wrote: Pablo, Sorry, but I think you're wrong. Only T-PE can insert the flow label (because only T=PE can be flow-aware). S-PE simply performs swap on PW label. Regards, Sasha - --- *From:* Pablo Frank [pablois...@gmail.com] *Sent:* Wednesday, August 17, 2011 12:17 AM *To:* Alexander Vainshtein *Cc:* ietf@ietf.org; m...@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal- in-pw I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS domain in the middle segment, you're no longer in an MPLS-TP environment and so the GAL is not required to be BOS. During that middle segment, the PW flow label would be placed below the GAL and above the GACh. It gets removed when it hits the S-PE that switches you back into the MPLS-TP environment. In other words, whether you're in an MPLS-TP environment is determined segment by segment in a MS- PW. Pablo On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein alexander.vainsht...@ecitele.com mailto:alexander.vainsht...@ecitele.com wrote: Hi all, After having sent out my comments I've noticed that the specific example
RE: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Pablo, This is not acceptable. Are you suggesting an LSR to pop a label that is not to of the stack? I can assure you 99.99% of HW out there can't do this. Thx SD From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Pablo Frank Sent: Tuesday, August 16, 2011 2:18 PM To: Alexander Vainshtein Cc: m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS domain in the middle segment, you're no longer in an MPLS-TP environment and so the GAL is not required to be BOS. During that middle segment, the PW flow label would be placed below the GAL and above the GACh. It gets removed when it hits the S-PE that switches you back into the MPLS-TP environment. In other words, whether you're in an MPLS-TP environment is determined segment by segment in a MS-PW. Pablo On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein alexander.vainsht...@ecitele.commailto:alexander.vainsht...@ecitele.com wrote: Hi all, After having sent out my comments I've noticed that the specific example to illustrate the need to combine GAL and flow label was inaccurate. A more relevant example would look like following (I do not include a diagram, but it can be easily provided if necessary) 1. A MS-PW: * Starts at an S-PE that resides at the edge of an MPLS-TP domain (no ECMP) * Crosses this domain and enters an IP/MPLS domain with ECMP enabled using a T-PE that resides at the age of these two domains * Leaves this domain and enters a 2nd MPLS-TP domain (using the 2nd T-PE) * Terminates on another S-PE at the edge of the 2nd MPLS-TP domain 1. The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertion and discard of flow labels at the two S-PEs. Note that: * This does not violate the MPLS-TP restriction on ECMP: ECMP does not happen in he MPLS-TP domains * T-PEs do not even have to be aware of flow labels 1. The operator also intends to operate some end-to-end OAM for this MS-PW using GAL-in-PW. This results in a conflict since both GAL and flow label are defined (in the corresponding drafts) as bottom of stack. IMHO this describes a realistic scenario where the two drafts are in controversy. Regards, Sasha From: mpls-boun...@ietf.orgmailto:mpls-boun...@ietf.org [mpls-boun...@ietf.orgmailto:mpls-boun...@ietf.org] On Behalf Of Alexander Vainshtein [alexander.vainsht...@ecitele.commailto:alexander.vainsht...@ecitele.com] Sent: Tuesday, August 16, 2011 4:26 PM To: ietf@ietf.orgmailto:ietf@ietf.org Cc: m...@ietf.orgmailto:m...@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Hi all, I would like to raise the following issue with regard to draft-ietf-pwe3-gal-in-pwhttp://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-tp-gal-in-pw/?include_text=1: controversy vs. draft-ietf-pwe3-fat-pwhttp://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/?include_text=1 with regard to bottom-of-stack position. As stated in the Introduction, this draft removes the restriction imposed by RFC 5586 on usage of Generic Associated Channel Label (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 states: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack(i.e., S bit set to 1). draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 5586 with the following In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). I.e., while removing this restriction of 5586, it does not modify its requirement for the GAL being always at the bottom of the label stack. At the same draft-ietf-pwe3-fat-pw (currently also in the IESG review) reserves the bottom of the PW stack for the PW flow labels, e.g., in Section 1.1: This document describes a method of adding an additional label stack entry (LSE) at the bottom of stack in order to facilitate the load balancing of the flows within a PW over the available ECMPs. One could argue that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO and FWIW, such an argument, were it presented, would be highly problematic, because: 1. RFC 5960 (which defines the MPLS-TP data plane) did not define any differences between the PW data plane in IP/MPLS and MPLS-TP. 2. One of the most popular scenarios for using multi-segment pseudowires
Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
My mistake. Flow-labels are used end-to-end in a multi-segment pseudowire. I suppose the flow label can easily be ignored when it crosses the MPLS-TP segments but that does create the conflict that Sasha is pointing out. Pablo On Tue, Aug 16, 2011 at 5:24 PM, Shahram Davari dav...@broadcom.com wrote: Pablo, ** ** This is not acceptable. Are you suggesting an LSR to pop a label that is not to of the stack? I can assure you 99.99% of HW out there can’t do this. ** ** Thx SD ** ** *From:* mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] *On Behalf Of *Pablo Frank *Sent:* Tuesday, August 16, 2011 2:18 PM *To:* Alexander Vainshtein *Cc:* m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen *Subject:* Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw ** ** I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS domain in the middle segment, you're no longer in an MPLS-TP environment and so the GAL is not required to be BOS. During that middle segment, the PW flow label would be placed below the GAL and above the GACh. It gets removed when it hits the S-PE that switches you back into the MPLS-TP environment. In other words, whether you're in an MPLS-TP environment is determined segment by segment in a MS-PW. ** ** Pablo On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein alexander.vainsht...@ecitele.com wrote: Hi all, After having sent out my comments I've noticed that the specific example to illustrate the need to combine GAL and flow label was inaccurate. A more relevant example would look like following (I do not include a diagram, but it can be easily provided if necessary) 1. A MS-PW: - Starts at an S-PE that resides at the edge of an MPLS-TP domain (no ECMP) - Crosses this domain and enters an IP/MPLS domain with ECMP enabled using a T-PE that resides at the age of these two domains - Leaves this domain and enters a 2nd MPLS-TP domain (using the 2nd T-PE) - Terminates on another S-PE at the edge of the 2nd MPLS-TP domain** ** 1. The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertion and discard of flow labels at the two S-PEs. Note that: - This does not violate the MPLS-TP restriction on ECMP: ECMP does not happen in he MPLS-TP domains - T-PEs do not even have to be aware of flow labels 1. The operator also intends to operate some end-to-end OAM for this MS-PW using GAL-in-PW. This results in a conflict since both GAL and flow label are defined (in the corresponding drafts) as bottom of stack.*** * IMHO this describes a realistic scenario where the two drafts are in controversy. Regards, Sasha -- *From:* mpls-boun...@ietf.org [mpls-boun...@ietf.org] On Behalf Of Alexander Vainshtein [alexander.vainsht...@ecitele.com] *Sent:* Tuesday, August 16, 2011 4:26 PM *To:* ietf@ietf.org *Cc:* m...@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Hi all, I would like to raise the following issue with regard to draft-ietf-pwe3-gal-in-pwhttp://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-tp-gal-in-pw/?include_text=1: controversy vs. draft-ietf-pwe3-fat-pwhttp://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/?include_text=1with regard to bottom-of-stack position. As stated in the Introduction, this draft removes the restriction imposed by RFC 5586 on usage of Generic Associated Channel Label (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 states: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack(i.e., S bit set to 1). draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 5586 with the following In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). I.e., while removing this restriction of 5586, it does not modify its requirement for the GAL being always at the bottom of the label stack. *** * At the same draft-ietf-pwe3-fat-pw (currently also in the IESG review) reserves the bottom of the PW stack for the PW flow labels, e.g., in Section 1.1: This document describes a method of adding an additional label stack entry (LSE) at the bottom of stack in order
RE: RE: [mpls] R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt and SPAM
guys - does EVERYONE need to see this - I've removed some of the list aliases to bcc - please be careful when you REPLY all -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of David Allan I Sent: Wednesday, July 13, 2011 11:24 PM To: erminio.ottone...@libero.it; l...@pi.nu; Rui Costa Cc: m...@ietf.org; ietf@ietf.org; IETF-Announce Subject: RE: RE: [mpls] R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard HI Erminio: The comments that were raised during the day long discussion with the editors at the SG15 plenary resulted in those comments appearing in the liasion IMO in an actionable form and resulted in a constructive outcome. I enjoyed that level of cooperation. The comments that were punted over the wall with no discussion (depsite requests to allocate meeting time to do so) in some cases were sufficiently vague as to have no constructive value or not have a recognizable issue to be addressed. A request to have the commenters identified in the liaison so that comments that were unclear could be followed up upon by the editors was refused. Apparently that is not done and I would go so far as to suggest that blanket of anonymity diminished the quality of the liaison. The result of this process was that the only recourse to go what does this mean? was a complete liaison cycle. For some comments, stomaching a multi-month delay to clarify what the actual issue was that resulted in a comment like describe the start-up procedure was not reasonable, especially given SG15s continual complaint on how slow the IETF was. Such comments had to be weighed against the nature of comments from the larger reviewing community that seemed to have no issue with the completeness of the document content and perhaps had actually read it and the supporting documents. I'll call out an example: a comment that appeared more than once in the liaison was clarify the raising/clearing of defects as well as any consequent actions which I can only interpret as section 3.7 of the document not having been read. E.g. the TOC is: 3.7.1. Session initiation and Modification 13 3.7.2. Defect entry criteria13 3.7.3. Defect entry consequent action 14 3.7.4. Defect exit criteria 15 3.7.5. State machines 15 ...and if there was a deficiency in the descriptions it was not identified, and we're not mind readers. So that is both the history and why some comments were rejected. If you can suggest a constructive way to proceed that is not simply a waste of everyone's time, I'll listen.. Cheers Dave -Original Message- From: erminio.ottone...@libero.it [mailto:erminio.ottone...@libero.it] Sent: Wednesday, July 13, 2011 1:28 PM To: David Allan I; l...@pi.nu; Rui Costa Cc: m...@ietf.org; ietf@ietf.org; IETF-Announce Subject: R: RE: [mpls] R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Do you mean that ITU-T comments were discussed and resolution agreed during the ITU-T meeting? If this is the case, why the LS just provides the comments and not the agreed resolution? Why some ITU-T comments have been then rejected? Messaggio originale Da: david.i.al...@ericsson.com Data: 6-lug-2011 19.35 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, l...@pi.nu l...@pi.nu, Rui Costarco...@ptinovacao.pt Cc: m...@ietf.orgm...@ietf.org, ietf@ietf.orgietf@ietf.org, IETF- Announceietf-annou...@ietf.org Ogg: RE: [mpls] R: Re: Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLSTransport Profile) to Proposed Standard Hi Erminio: Two of the three document editors were present at SG15 plenary in February where the comments originated. The revised meeting schedule resulted in a day spent going through the document with the editors. IMO there were lots of discussion and legitimate issues with the document identified and corrected so it was a useful session. The liaison of same was in many ways *after the fact*. Cheers Dave ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ This email has been scanned
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
On 07/13/2011 09:57 PM, Greg Mirsky wrote: Dear Erminio, I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to CCM is even more narrow then of the document being discussed. The G.8113.1 addresses only bi-directional co-routed LSP and has no model to handle bi-directional associated LSP in independent mode. And unidirectional p2p and p2mp LSPs are not addressed by the current revision of the G.8113.1. Can all these out-of-scope constructs be used to conclude that G.8113.1 is not capable to solve these issues? I don't think so. Solutions are not readily available, that's all. Can you guys all drop the ietf-announce list from this thread, please? This list is not for technical discussions. Thanks. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com www.asterisk.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
R: RE: [mpls] R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standa
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 This is not what the IETF has committed to deliver to ITU-T and in fact slide 44 postpones to the OAM design phase decide whether LSP-Ping or BFD can or should be tweaked or not and slide 46 reckons many options including non IP BFD is an option encapsulation of Y.1731 PDU It seems to me after having read the draft and followed this very long thread that tweaking BFD is not the right approach to meet ITU-T requirements so it would be worth evaluating the other alternative considered viable by the JWT which is encapulating Y.1731 PDUs. Messaggio originale Da: david.i.al...@ericsson.com Data: 6-lug-2011 20.24 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, rco...@ptinovacao.ptrco...@ptinovacao.pt, ietf@ietf.orgietf@ietf.org, IETF-Announceietf-annou...@ietf.org Cc: m...@ietf.orgm...@ietf.org Ogg: RE: [mpls] R: Re: LastCall: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive ConnectivityVerification, Continuity Check and Remote Defect indication for MPLSTransport 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
R: RE: [mpls] R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Stand
Do you mean that ITU-T comments were discussed and resolution agreed during the ITU-T meeting? If this is the case, why the LS just provides the comments and not the agreed resolution? Why some ITU-T comments have been then rejected? Messaggio originale Da: david.i.al...@ericsson.com Data: 6-lug-2011 19.35 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, l...@pi.nu l...@pi.nu, Rui Costarco...@ptinovacao.pt Cc: m...@ietf.orgm...@ietf.org, ietf@ietf.orgietf@ietf.org, IETF- Announceietf-annou...@ietf.org Ogg: RE: [mpls] R: Re: Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLSTransport Profile) to Proposed Standard Hi Erminio: Two of the three document editors were present at SG15 plenary in February where the comments originated. The revised meeting schedule resulted in a day spent going through the document with the editors. IMO there were lots of discussion and legitimate issues with the document identified and corrected so it was a useful session. The liaison of same was in many ways *after the fact*. Cheers Dave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
R: RE: [mpls] R: Re: LastCall: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification,Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard
The technical concern raised during the WG poll has not been resolved so the history definetely matters. Quoting RFC5921: There are thus two objectives for MPLS-TP: 1. To enable MPLS to be deployed in a transport network and operated in a similar manner to existing transport technologies. 2. To enable MPLS to support packet transport services with a similar degree of predictability to that found in existing transport networks. Based on the extensive comments provided by transport operators and ITU-T community, the solution in this draft is useless in case 1. The fact that the solution in this draft is not backward compatible with existing IP/MPLS BFD implementations means that this solution is also uselesee in case 2. Are there other undocumented use cases for MPLS-TP deployments? Messaggio originale Da: nurit.sprec...@nsn.com Data: 7-lug-2011 11.59 A: erminio.ottone...@libero.it, rco...@ptinovacao.pt, ietf@ietf.org, IETF-Announceietf-annou...@ietf.org Cc: m...@ietf.org Ogg: RE: [mpls] R: Re: LastCall: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive ConnectivityVerification,Continuity Check and Remote Defect indicationfor MPLSTransport Profile) to Proposed Standard Erminio, I do not think the history is relevant for this specific discussion... Also I find it inappropriate to give statements with no justifications behind. You say: the solution in this draft is useless for many MPLS-TP deployments.. in order to seriously consider your comment, you have to show why it is useless and which requirements are not satisfied. Otherwise you cannot expect anyone to refer to your point. Best regards, Nurit P.s. did you mean that the document is useless to available non-standard deployments, e.g. T-MPLS? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
R: RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard
I would not go so far as to say similar to 1731, there is actually a lot of difference under the hood. As for uni-directional BFD, that is a BFD WG problem at the moment. The fact that the BFD WG has not defined a solution for unidirectional p2p and p2mp transport paths does not make BFD a suitable OAM protocol for MPLS-TP nor does resolve the technical issue that have been raised. Messaggio originale Da: david.i.al...@ericsson.com Data: 8-lug-2011 18.13 A: Rui Costarco...@ptinovacao.pt, Stewart Bryantstbry...@cisco.com Cc: erminio.ottone...@libero.iterminio.ottone...@libero.it, mpls@ietf. orgm...@ietf.org, ietf@ietf.orgietf@ietf.org, IETF-Announceietf- annou...@ietf.org Ogg: RE: [mpls] Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard 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. Meanwhile as an editor of the document, I'll take the liberty of responding to some of the points you raise... 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. ...in a comparison session that took place during that same ITU-T meeting. 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 be detected, but on the list it was expressed that the group did not want the overhead of processing the source MEP TLV in every packet in order to achieve this. We could carry it in every packet and have the receiver simply ignore most of them, but then that would make the defect entry criteria compeltely random and the exit criteria unreliable as well, not really a good design. Hence they are separated using different ACH code points and the receiver is obliged to process every source MEP TLV it receives. I hope this is clear. (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) Because that puts you into two protocol ID demultiplexing steps per OAM PDU recevied to determine the intended function. Hence COSTS MORE. That is pretty basic... 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) I would not go so far as to say similar to 1731, there is actually a lot of difference under the hood. As for uni-directional BFD, that is a BFD WG problem at the moment. 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? It should. As for encapsulations, unless TP is in a complete island not connected to anything (which as a network is rather useless) it will be expected to interoperate with the rest of the MPLS architecture, and the stated intention of tool development was that what resulted was applicable to the broader MPLS architecture. Which means backwards compatiblity and procedures for interoperation. Backwards compatibility This was the main argument risen to ground MPLS-TP OAM on BFD. It's
R: RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard
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. The issue is not code point, which is the trivial part. It is reuse of the majority of the implementation. Again, pretty basic. I disagree. From a backward compatibility perspecting the codepoint is very relevant. An existing implementation does not reckon the new encapsulation: the only way to deploy this solution in a backward compatible manner is by upgrading all the IP/MPLS nodes that have been deployed up to so far. I think that the reuse of the majority of the implementation is actually the issue. Those implementations do not have the capabilities required to be deployed in a transport network. Developing a non-transport capable standard will not make these boxes transport capable but it would just make the standard useless for a transport environment. Messaggio originale Da: david.i.al...@ericsson.com Data: 8-lug-2011 18.13 A: Rui Costarco...@ptinovacao.pt, Stewart Bryantstbry...@cisco.com Cc: erminio.ottone...@libero.iterminio.ottone...@libero.it, mpls@ietf. orgm...@ietf.org, ietf@ietf.orgietf@ietf.org, IETF-Announceietf- annou...@ietf.org Ogg: RE: [mpls] Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard 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. Meanwhile as an editor of the document, I'll take the liberty of responding to some of the points you raise... 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. ...in a comparison session that took place during that same ITU-T meeting. 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 be detected, but on the list it was expressed that the group did not want the overhead of processing the source MEP TLV in every packet in order to achieve this. We could carry it in every packet and have the receiver simply ignore most of them, but then that would make the defect entry criteria compeltely random and the exit criteria unreliable as well, not really a good design. Hence they are separated using different ACH code points and the receiver is obliged to process every source MEP TLV it receives. I hope this is clear. (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) Because that puts you into two protocol ID demultiplexing steps per OAM PDU recevied to determine the intended function. Hence COSTS MORE. That is pretty basic... 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) I would not go so far as to say similar to 1731, there is actually a lot of difference under the hood. As for uni-directional BFD, that is a BFD WG problem at the moment. 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
RE: RE: [mpls] R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Stan
HI Erminio: The comments that were raised during the day long discussion with the editors at the SG15 plenary resulted in those comments appearing in the liasion IMO in an actionable form and resulted in a constructive outcome. I enjoyed that level of cooperation. The comments that were punted over the wall with no discussion (depsite requests to allocate meeting time to do so) in some cases were sufficiently vague as to have no constructive value or not have a recognizable issue to be addressed. A request to have the commenters identified in the liaison so that comments that were unclear could be followed up upon by the editors was refused. Apparently that is not done and I would go so far as to suggest that blanket of anonymity diminished the quality of the liaison. The result of this process was that the only recourse to go what does this mean? was a complete liaison cycle. For some comments, stomaching a multi-month delay to clarify what the actual issue was that resulted in a comment like describe the start-up procedure was not reasonable, especially given SG15s continual complaint on how slow the IETF was. Such comments had to be weighed against the nature of comments from the larger reviewing community that seemed to have no issue with the completeness of the document content and perhaps had actually read it and the supporting documents. I'll call out an example: a comment that appeared more than once in the liaison was clarify the raising/clearing of defects as well as any consequent actions which I can only interpret as section 3.7 of the document not having been read. E.g. the TOC is: 3.7.1. Session initiation and Modification 13 3.7.2. Defect entry criteria13 3.7.3. Defect entry consequent action 14 3.7.4. Defect exit criteria 15 3.7.5. State machines 15 ...and if there was a deficiency in the descriptions it was not identified, and we're not mind readers. So that is both the history and why some comments were rejected. If you can suggest a constructive way to proceed that is not simply a waste of everyone's time, I'll listen.. Cheers Dave -Original Message- From: erminio.ottone...@libero.it [mailto:erminio.ottone...@libero.it] Sent: Wednesday, July 13, 2011 1:28 PM To: David Allan I; l...@pi.nu; Rui Costa Cc: m...@ietf.org; ietf@ietf.org; IETF-Announce Subject: R: RE: [mpls] R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Do you mean that ITU-T comments were discussed and resolution agreed during the ITU-T meeting? If this is the case, why the LS just provides the comments and not the agreed resolution? Why some ITU-T comments have been then rejected? Messaggio originale Da: david.i.al...@ericsson.com Data: 6-lug-2011 19.35 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, l...@pi.nu l...@pi.nu, Rui Costarco...@ptinovacao.pt Cc: m...@ietf.orgm...@ietf.org, ietf@ietf.orgietf@ietf.org, IETF- Announceietf-annou...@ietf.org Ogg: RE: [mpls] R: Re: Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLSTransport Profile) to Proposed Standard Hi Erminio: Two of the three document editors were present at SG15 plenary in February where the comments originated. The revised meeting schedule resulted in a day spent going through the document with the editors. IMO there were lots of discussion and legitimate issues with the document identified and corrected so it was a useful session. The liaison of same was in many ways *after the fact*. Cheers Dave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mpls] R: RE: R: Re: LastCall: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Stan
Dear Erminio, even though I'm not an operator but I think that you've went bit too far in your first generalization. Every generalization is wrong, including this one Regards, Greg On Wed, Jul 13, 2011 at 1:32 PM, erminio.ottone...@libero.it erminio.ottone...@libero.it wrote: The technical concern raised during the WG poll has not been resolved so the history definetely matters. Quoting RFC5921: There are thus two objectives for MPLS-TP: 1. To enable MPLS to be deployed in a transport network and operated in a similar manner to existing transport technologies. 2. To enable MPLS to support packet transport services with a similar degree of predictability to that found in existing transport networks. Based on the extensive comments provided by transport operators and ITU-T community, the solution in this draft is useless in case 1. The fact that the solution in this draft is not backward compatible with existing IP/MPLS BFD implementations means that this solution is also uselesee in case 2. Are there other undocumented use cases for MPLS-TP deployments? Messaggio originale Da: nurit.sprec...@nsn.com Data: 7-lug-2011 11.59 A: erminio.ottone...@libero.it, rco...@ptinovacao.pt, ietf@ietf.org , IETF-Announceietf-annou...@ietf.org Cc: m...@ietf.org Ogg: RE: [mpls] R: Re: LastCall: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive ConnectivityVerification,Continuity Check and Remote Defect indicationfor MPLSTransport Profile) to Proposed Standard Erminio, I do not think the history is relevant for this specific discussion... Also I find it inappropriate to give statements with no justifications behind. You say: the solution in this draft is useless for many MPLS-TP deployments.. in order to seriously consider your comment, you have to show why it is useless and which requirements are not satisfied. Otherwise you cannot expect anyone to refer to your point. Best regards, Nurit P.s. did you mean that the document is useless to available non-standard deployments, e.g. T-MPLS? ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mpls] 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
Dear Erminio, I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to CCM is even more narrow then of the document being discussed. The G.8113.1 addresses only bi-directional co-routed LSP and has no model to handle bi-directional associated LSP in independent mode. And unidirectional p2p and p2mp LSPs are not addressed by the current revision of the G.8113.1. Can all these out-of-scope constructs be used to conclude that G.8113.1 is not capable to solve these issues? I don't think so. Solutions are not readily available, that's all. Regards, Greg On Wed, Jul 13, 2011 at 1:38 PM, erminio.ottone...@libero.it erminio.ottone...@libero.it wrote: I would not go so far as to say similar to 1731, there is actually a lot of difference under the hood. As for uni-directional BFD, that is a BFD WG problem at the moment. The fact that the BFD WG has not defined a solution for unidirectional p2p and p2mp transport paths does not make BFD a suitable OAM protocol for MPLS-TP nor does resolve the technical issue that have been raised. Messaggio originale Da: david.i.al...@ericsson.com Data: 8-lug-2011 18.13 A: Rui Costarco...@ptinovacao.pt, Stewart Bryantstbry...@cisco.com Cc: erminio.ottone...@libero.iterminio.ottone...@libero.it, mpls@ietf. orgm...@ietf.org, ietf@ietf.orgietf@ietf.org, IETF-Announceietf- annou...@ietf.org Ogg: RE: [mpls] Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard 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. Meanwhile as an editor of the document, I'll take the liberty of responding to some of the points you raise... 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. ...in a comparison session that took place during that same ITU-T meeting. 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 be detected, but on the list it was expressed that the group did not want the overhead of processing the source MEP TLV in every packet in order to achieve this. We could carry it in every packet and have the receiver simply ignore most of them, but then that would make the defect entry criteria compeltely random and the exit criteria unreliable as well, not really a good design. Hence they are separated using different ACH code points and the receiver is obliged to process every source MEP TLV it receives. I hope this is clear. (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) Because that puts you into two protocol ID demultiplexing steps per OAM PDU recevied to determine the intended function. Hence COSTS MORE. That is pretty basic... 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) I would not go so far as to say similar to 1731, there is actually a lot of difference under the hood. As for uni-directional BFD, that is a BFD WG problem at the moment. 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
R: RE: [mpls] R: RE: 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
The JWT report is aligned with my statement. The decision at IETF75 has been taken by the MPLS WG after the JWT and has never been endorsed by ITU-T (Huub is NOT ITU-T and, as far as I understood, he later removed his name because the other editors of the OAM Analysis draft were not considering his input to the document). The BFD-based solution accepted by IETF75 for pro-active CC/CV/RDI was completely different (and technically much superior) than the one described by this draft. Accepting a solution that meets the requirements does not mean signing a blank cheque that whichever changes is done is acceptable regarless whether it meets or not the requirements. Messaggio originale Da: jdr...@juniper.net Data: 13-lug-2011 22.46 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, david.i. al...@ericsson.comdavid.i.al...@ericsson.com, rco...@ptinovacao.pt rco...@ptinovacao.pt, ietf@ietf.orgietf@ietf.org, IETF-Announceietf- annou...@ietf.org Cc: m...@ietf.orgm...@ietf.org Ogg: RE: [mpls] R: RE: R: Re: LastCall: lt;draft-ietf-mpls-tp-cc-cv-rdi-05. txtgt; (Proactive ConnectivityVerification, Continuity Check and Remote Defect indication for MPLSTransport Profile) to Proposed Standard Italo, The design team report (http://www.ietf.org/proceedings/75/slides/mpls- 17/mpls-17_files/frame.htm), with Huub's name as an author, details a plan for MPLS-TP OAM which the MPLS WG has followed to this day. I think the report is compelling evidence that the claim that a packet transport network is an MPLS application that intrinsically requires a different OAM solution is simply a lame ex post facto attempt to justify the ITU's abrogation of the agreement with the IETF (TD07 (WP3/SG15) from December 2008 sourced by SG15): The ITU-T accepts these recommendations and states that any extensions to MPLS technology will be progressed via the IETF standards process using the procedures defined in RFC 4929 (Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures). Experts from the ITU-T will assist the IETF in the development of RFCs that describe the transport extensions by providing input to and review of the drafts as they are progressed via the IETF standards process.. The ITU-T will develop new or revised Recommendations that will allow IETF MPLS-TP to be integrated into the transport network including integration with the existing equipment, and operations infrastructure. These Recommendations will make normative references to the base IETF MPLS-TP technology and will be developed with input from and review by experts from the IETF to ensure consistency with MPLS-TP... The ITU-T has accepted the proposals from the JWT and we look forward to continuing the cooperative development of IETF MPLS to address the needs of the transport network. We also believe that this resolution will fulfil the mutual goal of improve the functionality of the internet and transport networks and guaranteeing complete interoperability and architectural soundness. Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of erminio.ottone...@libero.it Sent: Wednesday, July 13, 2011 1:27 PM To: david.i.al...@ericsson.com; rco...@ptinovacao.pt; ietf@ietf.org; IETF-Announce Cc: m...@ietf.org Subject: [mpls] R: RE: 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 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 This is not what the IETF has committed to deliver to ITU-T and in fact slide 44 postpones to the OAM design phase decide whether LSP-Ping or BFD can or should be tweaked or not and slide 46 reckons many options including non IP BFD is an option encapsulation of Y.1731 PDU It seems to me after having read the draft and followed this very long thread that tweaking BFD is not the right approach to meet ITU-T requirements so it would be worth evaluating the other alternative considered viable by the JWT which is encapulating Y.1731 PDUs. Messaggio originale Da: david.i.al...@ericsson.com Data: 6-lug-2011 20.24 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, rco...@ptinovacao.ptrco...@ptinovacao.pt, ietf@ietf.orgietf@ietf.org, IETF-Announceietf-annou...@ietf.org Cc: m...@ietf.orgm...@ietf.org Ogg: RE: [mpls] R: Re: Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi
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 Defectindication for MPLS Transport Profile) to Proposed Standard
Rui, I kindly propose not to refer in this context to the Feb2011 WP3 and SG15 plenary meetings Very unfortunately, it was far away from being a technical discussion.or technical poll. Therefore it cannot be a reference to any argument in this context. Regards, Nurit -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Rui Costa Sent: Thursday, July 14, 2011 8:33 PM To: David Allan I Cc: 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 Defectindication 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
Re: [mpls] R: RE: 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 St
To the extent that this particular debate (that of the nature scope and success or failure of the liaison effort) has been going on for some time: * it's not going to be resolved. * rehashing the history of how we came to this point it advances what agenda? It would seems timely in the IETF last call to focus the line of criticism on the merits or lack thereof of the draft as it stands, not on how we arrived here. joel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
R: RE: [mpls] R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standa
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 This is not what the IETF has committed to deliver to ITU-T and in fact slide 44 postpones to the OAM design phase decide whether LSP-Ping or BFD can or should be tweaked or not and slide 46 reckons many options including non IP BFD is an option encapsulation of Y.1731 PDU It seems to me after having read the draft and followed this very long thread that tweaking BFD is not the right approach to meet ITU-T requirements so it would be worth evaluating the other alternative considered viable by the JWT which is encapulating Y.1731 PDUs. Messaggio originale Da: david.i.al...@ericsson.com Data: 6-lug-2011 20.24 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, rco...@ptinovacao.ptrco...@ptinovacao.pt, i...@ietf.orgi...@ietf.org, IETF-Announceietf-announce@ietf.org Cc: m...@ietf.orgm...@ietf.org Ogg: RE: [mpls] R: Re: LastCall: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive ConnectivityVerification, Continuity Check and Remote Defect indication for MPLSTransport 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 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
R: RE: [mpls] R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Stand
Do you mean that ITU-T comments were discussed and resolution agreed during the ITU-T meeting? If this is the case, why the LS just provides the comments and not the agreed resolution? Why some ITU-T comments have been then rejected? Messaggio originale Da: david.i.al...@ericsson.com Data: 6-lug-2011 19.35 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, l...@pi.nu l...@pi.nu, Rui Costarco...@ptinovacao.pt Cc: m...@ietf.orgm...@ietf.org, i...@ietf.orgi...@ietf.org, IETF- Announceietf-announce@ietf.org Ogg: RE: [mpls] R: Re: Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLSTransport Profile) to Proposed Standard Hi Erminio: Two of the three document editors were present at SG15 plenary in February where the comments originated. The revised meeting schedule resulted in a day spent going through the document with the editors. IMO there were lots of discussion and legitimate issues with the document identified and corrected so it was a useful session. The liaison of same was in many ways *after the fact*. Cheers Dave ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
R: RE: [mpls] R: Re: LastCall: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification,Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard
The technical concern raised during the WG poll has not been resolved so the history definetely matters. Quoting RFC5921: There are thus two objectives for MPLS-TP: 1. To enable MPLS to be deployed in a transport network and operated in a similar manner to existing transport technologies. 2. To enable MPLS to support packet transport services with a similar degree of predictability to that found in existing transport networks. Based on the extensive comments provided by transport operators and ITU-T community, the solution in this draft is useless in case 1. The fact that the solution in this draft is not backward compatible with existing IP/MPLS BFD implementations means that this solution is also uselesee in case 2. Are there other undocumented use cases for MPLS-TP deployments? Messaggio originale Da: nurit.sprec...@nsn.com Data: 7-lug-2011 11.59 A: erminio.ottone...@libero.it, rco...@ptinovacao.pt, i...@ietf.org, IETF-Announceietf-announce@ietf.org Cc: m...@ietf.org Ogg: RE: [mpls] R: Re: LastCall: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive ConnectivityVerification,Continuity Check and Remote Defect indicationfor MPLSTransport Profile) to Proposed Standard Erminio, I do not think the history is relevant for this specific discussion... Also I find it inappropriate to give statements with no justifications behind. You say: the solution in this draft is useless for many MPLS-TP deployments.. in order to seriously consider your comment, you have to show why it is useless and which requirements are not satisfied. Otherwise you cannot expect anyone to refer to your point. Best regards, Nurit P.s. did you mean that the document is useless to available non-standard deployments, e.g. T-MPLS? ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
R: RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard
I would not go so far as to say similar to 1731, there is actually a lot of difference under the hood. As for uni-directional BFD, that is a BFD WG problem at the moment. The fact that the BFD WG has not defined a solution for unidirectional p2p and p2mp transport paths does not make BFD a suitable OAM protocol for MPLS-TP nor does resolve the technical issue that have been raised. Messaggio originale Da: david.i.al...@ericsson.com Data: 8-lug-2011 18.13 A: Rui Costarco...@ptinovacao.pt, Stewart Bryantstbry...@cisco.com Cc: erminio.ottone...@libero.iterminio.ottone...@libero.it, mpls@ietf. orgm...@ietf.org, i...@ietf.orgi...@ietf.org, IETF-Announceietf- annou...@ietf.org Ogg: RE: [mpls] Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard 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. Meanwhile as an editor of the document, I'll take the liberty of responding to some of the points you raise... 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. ...in a comparison session that took place during that same ITU-T meeting. 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 be detected, but on the list it was expressed that the group did not want the overhead of processing the source MEP TLV in every packet in order to achieve this. We could carry it in every packet and have the receiver simply ignore most of them, but then that would make the defect entry criteria compeltely random and the exit criteria unreliable as well, not really a good design. Hence they are separated using different ACH code points and the receiver is obliged to process every source MEP TLV it receives. I hope this is clear. (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) Because that puts you into two protocol ID demultiplexing steps per OAM PDU recevied to determine the intended function. Hence COSTS MORE. That is pretty basic... 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) I would not go so far as to say similar to 1731, there is actually a lot of difference under the hood. As for uni-directional BFD, that is a BFD WG problem at the moment. 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? It should. As for encapsulations, unless TP is in a complete island not connected to anything (which as a network is rather useless) it will be expected to interoperate with the rest of the MPLS architecture, and the stated intention of tool development was that what resulted was applicable to the broader MPLS architecture. Which means backwards compatiblity and procedures for interoperation. Backwards compatibility This was the main argument risen to ground MPLS-TP OAM on BFD. It's
R: RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard
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. The issue is not code point, which is the trivial part. It is reuse of the majority of the implementation. Again, pretty basic. I disagree. From a backward compatibility perspecting the codepoint is very relevant. An existing implementation does not reckon the new encapsulation: the only way to deploy this solution in a backward compatible manner is by upgrading all the IP/MPLS nodes that have been deployed up to so far. I think that the reuse of the majority of the implementation is actually the issue. Those implementations do not have the capabilities required to be deployed in a transport network. Developing a non-transport capable standard will not make these boxes transport capable but it would just make the standard useless for a transport environment. Messaggio originale Da: david.i.al...@ericsson.com Data: 8-lug-2011 18.13 A: Rui Costarco...@ptinovacao.pt, Stewart Bryantstbry...@cisco.com Cc: erminio.ottone...@libero.iterminio.ottone...@libero.it, mpls@ietf. orgm...@ietf.org, i...@ietf.orgi...@ietf.org, IETF-Announceietf- annou...@ietf.org Ogg: RE: [mpls] Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard 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. Meanwhile as an editor of the document, I'll take the liberty of responding to some of the points you raise... 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. ...in a comparison session that took place during that same ITU-T meeting. 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 be detected, but on the list it was expressed that the group did not want the overhead of processing the source MEP TLV in every packet in order to achieve this. We could carry it in every packet and have the receiver simply ignore most of them, but then that would make the defect entry criteria compeltely random and the exit criteria unreliable as well, not really a good design. Hence they are separated using different ACH code points and the receiver is obliged to process every source MEP TLV it receives. I hope this is clear. (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) Because that puts you into two protocol ID demultiplexing steps per OAM PDU recevied to determine the intended function. Hence COSTS MORE. That is pretty basic... 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) I would not go so far as to say similar to 1731, there is actually a lot of difference under the hood. As for uni-directional BFD, that is a BFD WG problem at the moment. 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
R: RE: [mpls] R: RE: 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
The JWT report is aligned with my statement. The decision at IETF75 has been taken by the MPLS WG after the JWT and has never been endorsed by ITU-T (Huub is NOT ITU-T and, as far as I understood, he later removed his name because the other editors of the OAM Analysis draft were not considering his input to the document). The BFD-based solution accepted by IETF75 for pro-active CC/CV/RDI was completely different (and technically much superior) than the one described by this draft. Accepting a solution that meets the requirements does not mean signing a blank cheque that whichever changes is done is acceptable regarless whether it meets or not the requirements. Messaggio originale Da: jdr...@juniper.net Data: 13-lug-2011 22.46 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, david.i. al...@ericsson.comdavid.i.al...@ericsson.com, rco...@ptinovacao.pt rco...@ptinovacao.pt, i...@ietf.orgi...@ietf.org, IETF-Announceietf- annou...@ietf.org Cc: m...@ietf.orgm...@ietf.org Ogg: RE: [mpls] R: RE: R: Re: LastCall: lt;draft-ietf-mpls-tp-cc-cv-rdi-05. txtgt; (Proactive ConnectivityVerification, Continuity Check and Remote Defect indication for MPLSTransport Profile) to Proposed Standard Italo, The design team report (http://www.ietf.org/proceedings/75/slides/mpls- 17/mpls-17_files/frame.htm), with Huub's name as an author, details a plan for MPLS-TP OAM which the MPLS WG has followed to this day. I think the report is compelling evidence that the claim that a packet transport network is an MPLS application that intrinsically requires a different OAM solution is simply a lame ex post facto attempt to justify the ITU's abrogation of the agreement with the IETF (TD07 (WP3/SG15) from December 2008 sourced by SG15): The ITU-T accepts these recommendations and states that any extensions to MPLS technology will be progressed via the IETF standards process using the procedures defined in RFC 4929 (Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures). Experts from the ITU-T will assist the IETF in the development of RFCs that describe the transport extensions by providing input to and review of the drafts as they are progressed via the IETF standards process.. The ITU-T will develop new or revised Recommendations that will allow IETF MPLS-TP to be integrated into the transport network including integration with the existing equipment, and operations infrastructure. These Recommendations will make normative references to the base IETF MPLS-TP technology and will be developed with input from and review by experts from the IETF to ensure consistency with MPLS-TP... The ITU-T has accepted the proposals from the JWT and we look forward to continuing the cooperative development of IETF MPLS to address the needs of the transport network. We also believe that this resolution will fulfil the mutual goal of improve the functionality of the internet and transport networks and guaranteeing complete interoperability and architectural soundness. Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of erminio.ottone...@libero.it Sent: Wednesday, July 13, 2011 1:27 PM To: david.i.al...@ericsson.com; rco...@ptinovacao.pt; i...@ietf.org; IETF-Announce Cc: m...@ietf.org Subject: [mpls] R: RE: 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 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 This is not what the IETF has committed to deliver to ITU-T and in fact slide 44 postpones to the OAM design phase decide whether LSP-Ping or BFD can or should be tweaked or not and slide 46 reckons many options including non IP BFD is an option encapsulation of Y.1731 PDU It seems to me after having read the draft and followed this very long thread that tweaking BFD is not the right approach to meet ITU-T requirements so it would be worth evaluating the other alternative considered viable by the JWT which is encapulating Y.1731 PDUs. Messaggio originale Da: david.i.al...@ericsson.com Data: 6-lug-2011 20.24 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, rco...@ptinovacao.ptrco...@ptinovacao.pt, i...@ietf.orgi...@ietf.org, IETF-Announceietf-announce@ietf.org Cc: m...@ietf.orgm...@ietf.org Ogg: RE: [mpls] R: Re: Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi
RE: RE: [mpls] R: RE: 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 Propose
Italo, Comments inline. Thanks, John Sent from my iPhone -Original Message- From: erminio.ottone...@libero.it [mailto:erminio.ottone...@libero.it] Sent: Wednesday, July 13, 2011 2:04 PM To: John E Drake; david.i.al...@ericsson.com; rco...@ptinovacao.pt; i...@ietf.org; IETF-Announce Cc: m...@ietf.org Subject: R: RE: [mpls] R: RE: 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 The JWT report is aligned with my statement. JD: As SG15 management is fond of pointing out, when it suits them, the JWT operated on a very compressed time scale and didn't fully explore all of the technical issues The decision at IETF75 has been taken by the MPLS WG after the JWT and has never been endorsed by ITU-T (Huub is NOT ITU-T and, as far as I understood, he later removed his name because the other editors of the OAM Analysis draft were not considering his input to the document). JD: I'm not sure what your point is The BFD-based solution accepted by IETF75 for pro-active CC/CV/RDI was completely different (and technically much superior) than the one described by this draft. JD: Obviously we disagree Accepting a solution that meets the requirements does not mean signing a blank cheque that whichever changes is done is acceptable regarless whether it meets or not the requirements. JD: The requirements as documented in RFCs 5654, 5860, and 5951, or the requirements that seem to change based upon the phases of the moon? Messaggio originale Da: jdr...@juniper.net Data: 13-lug-2011 22.46 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, david.i. al...@ericsson.comdavid.i.al...@ericsson.com, rco...@ptinovacao.pt rco...@ptinovacao.pt, i...@ietf.orgi...@ietf.org, IETF- Announceietf- annou...@ietf.org Cc: m...@ietf.orgm...@ietf.org Ogg: RE: [mpls] R: RE: R: Re:LastCall: lt;draft-ietf-mpls-tp- cc-cv-rdi-05. txtgt; (Proactive ConnectivityVerification, Continuity Check and Remote Defectindication for MPLSTransport Profile) to Proposed Standard Italo, The design team report (http://www.ietf.org/proceedings/75/slides/mpls- 17/mpls-17_files/frame.htm), with Huub's name as an author, details a plan for MPLS-TP OAM which the MPLS WG has followed to this day. I think the report is compelling evidence that the claim that a packet transport network is an MPLS application that intrinsically requires a different OAM solution is simply a lame ex post facto attempt to justify the ITU's abrogation of the agreement with the IETF (TD07 (WP3/SG15) from December 2008 sourced by SG15): The ITU-T accepts these recommendations and states that any extensions to MPLS technology will be progressed via the IETF standards process using the procedures defined in RFC 4929 (Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures). Experts from the ITU-T will assist the IETF in the development of RFCs that describe the transport extensions by providing input to and review of the drafts as they are progressed via the IETF standards process.. The ITU- T will develop new or revised Recommendations that will allow IETF MPLS-TP to be integrated into the transport network including integration with the existing equipment, and operations infrastructure. These Recommendations will make normative references to the base IETF MPLS-TP technology and will be developed with input from and review by experts from the IETF to ensure consistency with MPLS-TP... The ITU-T has accepted the proposals from the JWT and we look forward to continuing the cooperative development of IETF MPLS to address the needs of the transport network. We also believe that this resolution will fulfil the mutual goal of improve the functionality of the internet and transport networks and guaranteeing complete interoperability and architectural soundness. Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of erminio.ottone...@libero.it Sent: Wednesday, July 13, 2011 1:27 PM To: david.i.al...@ericsson.com; rco...@ptinovacao.pt; i...@ietf.org; IETF-Announce Cc: m...@ietf.org Subject: [mpls] R: RE: 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 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
Re: [mpls] R: RE: R: Re: LastCall: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Stan
Dear Erminio, even though I'm not an operator but I think that you've went bit too far in your first generalization. Every generalization is wrong, including this one Regards, Greg On Wed, Jul 13, 2011 at 1:32 PM, erminio.ottone...@libero.it erminio.ottone...@libero.it wrote: The technical concern raised during the WG poll has not been resolved so the history definetely matters. Quoting RFC5921: There are thus two objectives for MPLS-TP: 1. To enable MPLS to be deployed in a transport network and operated in a similar manner to existing transport technologies. 2. To enable MPLS to support packet transport services with a similar degree of predictability to that found in existing transport networks. Based on the extensive comments provided by transport operators and ITU-T community, the solution in this draft is useless in case 1. The fact that the solution in this draft is not backward compatible with existing IP/MPLS BFD implementations means that this solution is also uselesee in case 2. Are there other undocumented use cases for MPLS-TP deployments? Messaggio originale Da: nurit.sprec...@nsn.com Data: 7-lug-2011 11.59 A: erminio.ottone...@libero.it, rco...@ptinovacao.pt, i...@ietf.org , IETF-Announceietf-announce@ietf.org Cc: m...@ietf.org Ogg: RE: [mpls] R: Re: LastCall: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive ConnectivityVerification,Continuity Check and Remote Defect indicationfor MPLSTransport Profile) to Proposed Standard Erminio, I do not think the history is relevant for this specific discussion... Also I find it inappropriate to give statements with no justifications behind. You say: the solution in this draft is useless for many MPLS-TP deployments.. in order to seriously consider your comment, you have to show why it is useless and which requirements are not satisfied. Otherwise you cannot expect anyone to refer to your point. Best regards, Nurit P.s. did you mean that the document is useless to available non-standard deployments, e.g. T-MPLS? ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
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
Dear Erminio, I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to CCM is even more narrow then of the document being discussed. The G.8113.1 addresses only bi-directional co-routed LSP and has no model to handle bi-directional associated LSP in independent mode. And unidirectional p2p and p2mp LSPs are not addressed by the current revision of the G.8113.1. Can all these out-of-scope constructs be used to conclude that G.8113.1 is not capable to solve these issues? I don't think so. Solutions are not readily available, that's all. Regards, Greg On Wed, Jul 13, 2011 at 1:38 PM, erminio.ottone...@libero.it erminio.ottone...@libero.it wrote: I would not go so far as to say similar to 1731, there is actually a lot of difference under the hood. As for uni-directional BFD, that is a BFD WG problem at the moment. The fact that the BFD WG has not defined a solution for unidirectional p2p and p2mp transport paths does not make BFD a suitable OAM protocol for MPLS-TP nor does resolve the technical issue that have been raised. Messaggio originale Da: david.i.al...@ericsson.com Data: 8-lug-2011 18.13 A: Rui Costarco...@ptinovacao.pt, Stewart Bryantstbry...@cisco.com Cc: erminio.ottone...@libero.iterminio.ottone...@libero.it, mpls@ietf. orgm...@ietf.org, i...@ietf.orgi...@ietf.org, IETF-Announceietf- annou...@ietf.org Ogg: RE: [mpls] Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard 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. Meanwhile as an editor of the document, I'll take the liberty of responding to some of the points you raise... 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. ...in a comparison session that took place during that same ITU-T meeting. 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 be detected, but on the list it was expressed that the group did not want the overhead of processing the source MEP TLV in every packet in order to achieve this. We could carry it in every packet and have the receiver simply ignore most of them, but then that would make the defect entry criteria compeltely random and the exit criteria unreliable as well, not really a good design. Hence they are separated using different ACH code points and the receiver is obliged to process every source MEP TLV it receives. I hope this is clear. (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) Because that puts you into two protocol ID demultiplexing steps per OAM PDU recevied to determine the intended function. Hence COSTS MORE. That is pretty basic... 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) I would not go so far as to say similar to 1731, there is actually a lot of difference under the hood. As for uni-directional BFD, that is a BFD WG problem at the moment. 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
RE: [mpls] R: RE: 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 St
Italo, The design team report (http://www.ietf.org/proceedings/75/slides/mpls-17/mpls-17_files/frame.htm), with Huub's name as an author, details a plan for MPLS-TP OAM which the MPLS WG has followed to this day. I think the report is compelling evidence that the claim that a packet transport network is an MPLS application that intrinsically requires a different OAM solution is simply a lame ex post facto attempt to justify the ITU's abrogation of the agreement with the IETF (TD07 (WP3/SG15) from December 2008 sourced by SG15): The ITU-T accepts these recommendations and states that any extensions to MPLS technology will be progressed via the IETF standards process using the procedures defined in RFC 4929 (Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures). Experts from the ITU-T will assist the IETF in the development of RFCs that describe the transport extensions by providing input to and review of the drafts as they are progressed via the IETF standards process.. The ITU-T will develop new or revised Recommendations that will allow IETF MPLS-TP to be integrated into the transport network including integration with the existing equipment, and operations infrastructure. These Recommendations will make normative references to the base IETF MPLS-TP technology and will be developed with input from and review by experts from the IETF to ensure consistency with MPLS-TP... The ITU-T has accepted the proposals from the JWT and we look forward to continuing the cooperative development of IETF MPLS to address the needs of the transport network. We also believe that this resolution will fulfil the mutual goal of improve the functionality of the internet and transport networks and guaranteeing complete interoperability and architectural soundness. Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of erminio.ottone...@libero.it Sent: Wednesday, July 13, 2011 1:27 PM To: david.i.al...@ericsson.com; rco...@ptinovacao.pt; ietf@ietf.org; IETF-Announce Cc: m...@ietf.org Subject: [mpls] R: RE: 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 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 This is not what the IETF has committed to deliver to ITU-T and in fact slide 44 postpones to the OAM design phase decide whether LSP-Ping or BFD can or should be tweaked or not and slide 46 reckons many options including non IP BFD is an option encapsulation of Y.1731 PDU It seems to me after having read the draft and followed this very long thread that tweaking BFD is not the right approach to meet ITU-T requirements so it would be worth evaluating the other alternative considered viable by the JWT which is encapulating Y.1731 PDUs. Messaggio originale Da: david.i.al...@ericsson.com Data: 6-lug-2011 20.24 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, rco...@ptinovacao.ptrco...@ptinovacao.pt, ietf@ietf.orgietf@ietf.org, IETF-Announceietf-annou...@ietf.org Cc: m...@ietf.orgm...@ietf.org Ogg: RE: [mpls] R: Re: Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi- 05.txtgt; (ProactiveConnectivityVerification, Continuity Check and Remote Defect indicationfor MPLSTransport 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
RE: RE: [mpls] R: RE: 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 Propose
Italo, Comments inline. Thanks, John Sent from my iPhone -Original Message- From: erminio.ottone...@libero.it [mailto:erminio.ottone...@libero.it] Sent: Wednesday, July 13, 2011 2:04 PM To: John E Drake; david.i.al...@ericsson.com; rco...@ptinovacao.pt; ietf@ietf.org; IETF-Announce Cc: m...@ietf.org Subject: R: RE: [mpls] R: RE: 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 The JWT report is aligned with my statement. JD: As SG15 management is fond of pointing out, when it suits them, the JWT operated on a very compressed time scale and didn't fully explore all of the technical issues The decision at IETF75 has been taken by the MPLS WG after the JWT and has never been endorsed by ITU-T (Huub is NOT ITU-T and, as far as I understood, he later removed his name because the other editors of the OAM Analysis draft were not considering his input to the document). JD: I'm not sure what your point is The BFD-based solution accepted by IETF75 for pro-active CC/CV/RDI was completely different (and technically much superior) than the one described by this draft. JD: Obviously we disagree Accepting a solution that meets the requirements does not mean signing a blank cheque that whichever changes is done is acceptable regarless whether it meets or not the requirements. JD: The requirements as documented in RFCs 5654, 5860, and 5951, or the requirements that seem to change based upon the phases of the moon? Messaggio originale Da: jdr...@juniper.net Data: 13-lug-2011 22.46 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, david.i. al...@ericsson.comdavid.i.al...@ericsson.com, rco...@ptinovacao.pt rco...@ptinovacao.pt, ietf@ietf.orgietf@ietf.org, IETF- Announceietf- annou...@ietf.org Cc: m...@ietf.orgm...@ietf.org Ogg: RE: [mpls] R: RE: R: Re:LastCall: lt;draft-ietf-mpls-tp- cc-cv-rdi-05. txtgt; (Proactive ConnectivityVerification, Continuity Check and Remote Defectindication for MPLSTransport Profile) to Proposed Standard Italo, The design team report (http://www.ietf.org/proceedings/75/slides/mpls- 17/mpls-17_files/frame.htm), with Huub's name as an author, details a plan for MPLS-TP OAM which the MPLS WG has followed to this day. I think the report is compelling evidence that the claim that a packet transport network is an MPLS application that intrinsically requires a different OAM solution is simply a lame ex post facto attempt to justify the ITU's abrogation of the agreement with the IETF (TD07 (WP3/SG15) from December 2008 sourced by SG15): The ITU-T accepts these recommendations and states that any extensions to MPLS technology will be progressed via the IETF standards process using the procedures defined in RFC 4929 (Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures). Experts from the ITU-T will assist the IETF in the development of RFCs that describe the transport extensions by providing input to and review of the drafts as they are progressed via the IETF standards process.. The ITU- T will develop new or revised Recommendations that will allow IETF MPLS-TP to be integrated into the transport network including integration with the existing equipment, and operations infrastructure. These Recommendations will make normative references to the base IETF MPLS-TP technology and will be developed with input from and review by experts from the IETF to ensure consistency with MPLS-TP... The ITU-T has accepted the proposals from the JWT and we look forward to continuing the cooperative development of IETF MPLS to address the needs of the transport network. We also believe that this resolution will fulfil the mutual goal of improve the functionality of the internet and transport networks and guaranteeing complete interoperability and architectural soundness. Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of erminio.ottone...@libero.it Sent: Wednesday, July 13, 2011 1:27 PM To: david.i.al...@ericsson.com; rco...@ptinovacao.pt; ietf@ietf.org; IETF-Announce Cc: m...@ietf.org Subject: [mpls] R: RE: 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 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
RE: [mpls] R: RE: R: Re: LastCall: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Stan
Erminio Hi, I belong to an Operator, I strongly agree with Greg. Regards Medel From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Greg Mirsky Sent: Thursday, July 14, 2011 10:50 AM To: erminio.ottone...@libero.it Cc: m...@ietf.org; IETF-Announce; ietf@ietf.org Subject: Re: [mpls] R: RE: R: Re: LastCall: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard Dear Erminio, even though I'm not an operator but I think that you've went bit too far in your first generalization. Every generalization is wrong, including this one Regards, Greg On Wed, Jul 13, 2011 at 1:32 PM, erminio.ottone...@libero.it erminio.ottone...@libero.it wrote: The technical concern raised during the WG poll has not been resolved so the history definetely matters. Quoting RFC5921: There are thus two objectives for MPLS-TP: 1. To enable MPLS to be deployed in a transport network and operated in a similar manner to existing transport technologies. 2. To enable MPLS to support packet transport services with a similar degree of predictability to that found in existing transport networks. Based on the extensive comments provided by transport operators and ITU-T community, the solution in this draft is useless in case 1. The fact that the solution in this draft is not backward compatible with existing IP/MPLS BFD implementations means that this solution is also uselesee in case 2. Are there other undocumented use cases for MPLS-TP deployments? Messaggio originale Da: nurit.sprec...@nsn.com Data: 7-lug-2011 11.59 A: erminio.ottone...@libero.it, rco...@ptinovacao.pt, ietf@ietf.org, IETF-Announceietf-annou...@ietf.org Cc: m...@ietf.org Ogg: RE: [mpls] R: Re: LastCall: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive ConnectivityVerification,Continuity Check and Remote Defect indicationfor MPLSTransport Profile) to Proposed Standard Erminio, I do not think the history is relevant for this specific discussion... Also I find it inappropriate to give statements with no justifications behind. You say: the solution in this draft is useless for many MPLS-TP deployments.. in order to seriously consider your comment, you have to show why it is useless and which requirements are not satisfied. Otherwise you cannot expect anyone to refer to your point. Best regards, Nurit P.s. did you mean that the document is useless to available non-standard deployments, e.g. T-MPLS? ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message (including attachments, if any) is intended for the use of the individual or the entity to whom it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete this E-mail message immediately. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard
is the key for reliable fail finger pointing, performance reports and protection. Also to allow scaling, more implementation opportunities/manufacturers, which is valuable for operators. Well IMO there was not a lot of interest in T-MPLS until the IETF was going to re-define it and make it compatible with IP/MPLS. So there was an industry wide design intent implied here. IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which. That is because MPLS-TP is not a new techology, it is an addition to the entire MPLS protocol suite. Hope this helps D -Original Message- From: David Allan I [mailto:david.i.al...@ericsson.com] Sent: quarta-feira, 6 de Julho de 2011 19:25 To: erminio.ottone...@libero.it; Rui Costa; ietf@ietf.org; IETF-Announce Cc: m...@ietf.org Subject: RE: [mpls] R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Hi Erminio: snipped Several service providers regarded this draft as not meeting their transport networks' needs. E This is a true statement: the solution in this draft is useless for many MPLS- TP deployments. The two statements do not necessarily follow. What we established during discussions at the SG15 plenary in February was that the issue some service providers had was that the IETF BFD solution exceeded their requirements in that there was additional functionality they did not see a need for, and that they considered any additional functionality parasitic. However this is a consequence of adapting an existing technology to a new application. I do not see any way around that. And the entire joint project was based on the premise of engineering re-use not greenfield design. That is what it said on the tin up front, and IMO why when the IETF started down this path packet transport transitioned from being a minority sport to mainstream, so it is a bit late to cry foul My 2 cents Dave -Original Message- From: David Allan I [mailto:david.i.al...@ericsson.com] Sent: quarta-feira, 6 de Julho de 2011 18:36 To: erminio.ottone...@libero.it; l...@pi.nu; Rui Costa Cc: m...@ietf.org; ietf@ietf.org; IETF-Announce Subject: RE: [mpls] R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Hi Erminio: Two of the three document editors were present at SG15 plenary in February where the comments originated. The revised meeting schedule resulted in a day spent going through the document with the editors. IMO there were lots of discussion and legitimate issues with the document identified and corrected so it was a useful session. The liaison of same was in many ways *after the fact*. Cheers Dave -Original Message- From: erminio.ottone...@libero.it [mailto:erminio.ottone...@libero.it] Sent: quarta-feira, 6 de Julho de 2011 18:34 To: Rui Costa; ietf@ietf.org; IETF-Announce Cc: m...@ietf.org Subject: R: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard The way this draft has been developed is a bit strange. The poll for its adoption as a WG document was halted by the MPLS WG chair because it is not possible to judge consensus: http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html The lack of consensus was motivated by serious technical concerns raised by several transport experts during the poll. Nevertheless the MPLS WG chair decided to adopt the draft as a WG document: http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html After several WG revisions and WG LCs, the technical issues have not been resolved. Several service providers regarded this draft as not meeting their transport networks' needs. This is a true statement: the solution in this draft is useless for many MPLS- TP deployments. -Original Message- From: erminio.ottone...@libero.it [mailto:erminio.ottone...@libero.it] Sent: quarta-feira, 6 de Julho de 2011 18:26 To: l...@pi.nu; Rui Costa Cc: m...@ietf.org; ietf@ietf.org; IETF-Announce Subject: R: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Version -04 of the document was published June 28th. The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent June 29th. So when the WG LC to confirm the LC comment resolution has been launched? The proto write-up says: It has also passed a working roup call to verify that LC comments were correctly with minor comments. It also says: The comments has been carefully discussed between
RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard
Thanks Tom...these are general observations which I think are valid and respond to Rui's point about the need for simplicityand they are as much directed to folks pushing overblown OAM in ITU as folks in IETF. You may of course disagree with them. I recall someone once saying MPLS did not need DP OAM at all regards, Neil -Original Message- From: Thomas Nadeau [mailto:tnad...@lucidvision.com] Sent: 08 July 2011 16:27 To: Harrison,N,Neil,DKQ7 R Cc: rco...@ptinovacao.pt; david.i.al...@ericsson.com; stbry...@cisco.com; m...@ietf.org; ietf@ietf.org; ietf- annou...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard On Jul 8, 2011, at 3:15 AM, neil.2.harri...@bt.com wrote: Got to say I agree with Rui on much of what he says here. And I absolutely resonate with his point on the need for simplicity. The reason OAM needs to be as simple as possible is because it must be super reliablewe do not want to consciously build in weaknesses, esp unnecessary ones this also implies minimal config. We could all do better on this. For example: - Rui is dead right a CC function is fairly useless, we only need a CV function...the ATM OAM in I.610 suffers from this problem (and few others like AIS and the assumed use of request/response MLT to diagnose leaking/mismerging traffic...request/response OAM won't work with unidirectional defects). While you are entitled to your opinion, I personally think there are enough requirements elsewhere to have both CC and CV functions. But we digress. Are you actually asking that the CC functionality be removed from the draft or just making a general comment? - all packet layer networks should not have an AIS OAM messagevery obvious for the cl-ps mode of course. The co-ps mode is also not like the co-cs mode. One has to consciously manufacture AIS messages and target them to specific clients in the co-ps modewho may have taken action in their own layer network and 'moved elsewhere' anyway, ie a total waste of time now. AIS is actually unnecessary wrt providing information anyway, it simply represents an in-built weakness of just something else to go wrong which itself will create problems. What does that comment have to do with the actual draft in question? - creating preconfigured TCM sublayers is just asking for trouble IMO. It is far smarter to simply create a single end-end OAM CV (and when required PM) flow and tap this off at intermediate nodes on the *rare* occasions one wants to do. Again, what does this have to do with the actual draft in question? --tom regards, Neil This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 180 -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Rui Costa Sent: 08 July 2011 01:15 To: David Allan I; Stewart Bryant Cc: ietf@ietf.org; IETF-Announce; m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard David, Reading something, keeping it on record, without effect in the draft and ignoring comments have IMHO similar outcomes. As author of the draft you are free to do it. These standards have a great impact in our work, so i'm also free to write what i did. Stewart, My technical concerns regarding this draft were expressed... ...in the (ITU-T - IETF, Feb/2011) liaison regarding it (LS281, i believe); ...in operators' meetings' that took place during ITU-T's Feb/2011 plenary meeting; ...in a comparison session that took place during that same ITU-T meeting. Some: CC/CV I don't understand the need for 2 types of packets: a single type allows CC; mismatching identifiers in the same CC packets allow CV. Besides adding complexity, we whether always activate both or potentiate undetected mismerges. (BTW: can't understand how we propose one ACH codepoint to CC, another for CV, [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
RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard
I think there is some confusion here The only CC in isolation in the draft is the option to use RFC 5885. Which then is a network design issue. Draft cc-cv-rdi used by itself is CV always on. It is just not EVERY PDU that requires CV processing so there are CC and CV PDUs interleaved. Mis-connectivity detection is network wide and fairly authoritative (unless we are discussing a mode of failure in which only some packets leak, which means even an always on CV may not be so unlucky as to leak and be detected). So I think we are in agreement on that front... Dave -Original Message- From: Thomas Nadeau [mailto:tnad...@lucidvision.com] Sent: Friday, July 08, 2011 8:27 AM To: neil.2.harri...@bt.com Cc: rco...@ptinovacao.pt; David Allan I; stbry...@cisco.com; m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard On Jul 8, 2011, at 3:15 AM, neil.2.harri...@bt.com wrote: Got to say I agree with Rui on much of what he says here. And I absolutely resonate with his point on the need for simplicity. The reason OAM needs to be as simple as possible is because it must be super reliablewe do not want to consciously build in weaknesses, esp unnecessary ones this also implies minimal config. We could all do better on this. For example: - Rui is dead right a CC function is fairly useless, we only need a CV function...the ATM OAM in I.610 suffers from this problem (and few others like AIS and the assumed use of request/response MLT to diagnose leaking/mismerging traffic...request/response OAM won't work with unidirectional defects). While you are entitled to your opinion, I personally think there are enough requirements elsewhere to have both CC and CV functions. But we digress. Are you actually asking that the CC functionality be removed from the draft or just making a general comment? - all packet layer networks should not have an AIS OAM messagevery obvious for the cl-ps mode of course. The co-ps mode is also not like the co-cs mode. One has to consciously manufacture AIS messages and target them to specific clients in the co-ps modewho may have taken action in their own layer network and 'moved elsewhere' anyway, ie a total waste of time now. AIS is actually unnecessary wrt providing information anyway, it simply represents an in-built weakness of just something else to go wrong which itself will create problems. What does that comment have to do with the actual draft in question? - creating preconfigured TCM sublayers is just asking for trouble IMO. It is far smarter to simply create a single end-end OAM CV (and when required PM) flow and tap this off at intermediate nodes on the *rare* occasions one wants to do. Again, what does this have to do with the actual draft in question? --tom regards, Neil This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 180 -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Rui Costa Sent: 08 July 2011 01:15 To: David Allan I; Stewart Bryant Cc: ietf@ietf.org; IETF-Announce; m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard David, Reading something, keeping it on record, without effect in the draft and ignoring comments have IMHO similar outcomes. As author of the draft you are free to do it. These standards have a great impact in our work, so i'm also free to write what i did. Stewart, My technical concerns regarding this draft were expressed... ...in the (ITU-T - IETF, Feb/2011) liaison regarding it (LS281, i believe); ...in operators' meetings' that took place during ITU-T's Feb/2011 plenary meeting; ...in a comparison session that took place during that same ITU-T meeting. Some: CC/CV I don't understand the need for 2 types of packets: a single type allows CC; mismatching identifiers in the same CC packets allow CV. Besides adding complexity, we whether always activate both or potentiate undetected mismerges. (BTW: can't understand how we propose one ACH codepoint to CC, another for CV
RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard
Thanks Dave. If we don't have this (ie CV function on all connections/LSPs) then there is potential security risk wrt leaking traffic. Note that besides trad nested sublayered LSPs in the same layer network this also applies to nested LSPs belonging to different MPLS-TP layer networks (may be same or different party ownership). This point about the OAM CV function also ought to be captured in any security drafts. regards, Neil -Original Message- From: David Allan I [mailto:david.i.al...@ericsson.com] Sent: 08 July 2011 17:30 To: Thomas Nadeau; Harrison,N,Neil,DKQ7 R Cc: rco...@ptinovacao.pt; stbry...@cisco.com; m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard I think there is some confusion here The only CC in isolation in the draft is the option to use RFC 5885. Which then is a network design issue. Draft cc-cv-rdi used by itself is CV always on. It is just not EVERY PDU that requires CV processing so there are CC and CV PDUs interleaved. Mis-connectivity detection is network wide and fairly authoritative (unless we are discussing a mode of failure in which only some packets leak, which means even an always on CV may not be so unlucky as to leak and be detected). So I think we are in agreement on that front... Dave -Original Message- From: Thomas Nadeau [mailto:tnad...@lucidvision.com] Sent: Friday, July 08, 2011 8:27 AM To: neil.2.harri...@bt.com Cc: rco...@ptinovacao.pt; David Allan I; stbry...@cisco.com; m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard On Jul 8, 2011, at 3:15 AM, neil.2.harri...@bt.com wrote: Got to say I agree with Rui on much of what he says here. And I absolutely resonate with his point on the need for simplicity. The reason OAM needs to be as simple as possible is because it must be super reliablewe do not want to consciously build in weaknesses, esp unnecessary ones this also implies minimal config. We could all do better on this. For example: - Rui is dead right a CC function is fairly useless, we only need a CV function...the ATM OAM in I.610 suffers from this problem (and few others like AIS and the assumed use of request/response MLT to diagnose leaking/mismerging traffic...request/response OAM won't work with unidirectional defects). While you are entitled to your opinion, I personally think there are enough requirements elsewhere to have both CC and CV functions. But we digress. Are you actually asking that the CC functionality be removed from the draft or just making a general comment? - all packet layer networks should not have an AIS OAM messagevery obvious for the cl-ps mode of course. The co-ps mode is also not like the co-cs mode. One has to consciously manufacture AIS messages and target them to specific clients in the co-ps modewho may have taken action in their own layer network and 'moved elsewhere' anyway, ie a total waste of time now. AIS is actually unnecessary wrt providing information anyway, it simply represents an in-built weakness of just something else to go wrong which itself will create problems. What does that comment have to do with the actual draft in question? - creating preconfigured TCM sublayers is just asking for trouble IMO. It is far smarter to simply create a single end-end OAM CV (and when required PM) flow and tap this off at intermediate nodes on the *rare* occasions one wants to do. Again, what does this have to do with the actual draft in question? --tom regards, Neil This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 180 -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Rui Costa Sent: 08 July 2011 01:15 To: David Allan I; Stewart Bryant Cc: ietf@ietf.org; IETF-Announce; m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport
RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard
Hi Neil: As a result of Adrians AD review, some text to that effect was added to the Security Considerations section. Have a good weekend Dave -Original Message- From: neil.2.harri...@bt.com [mailto:neil.2.harri...@bt.com] Sent: Friday, July 08, 2011 9:40 AM To: David Allan I; tnad...@lucidvision.com Cc: rco...@ptinovacao.pt; stbry...@cisco.com; m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thanks Dave. If we don't have this (ie CV function on all connections/LSPs) then there is potential security risk wrt leaking traffic. Note that besides trad nested sublayered LSPs in the same layer network this also applies to nested LSPs belonging to different MPLS-TP layer networks (may be same or different party ownership). This point about the OAM CV function also ought to be captured in any security drafts. regards, Neil -Original Message- From: David Allan I [mailto:david.i.al...@ericsson.com] Sent: 08 July 2011 17:30 To: Thomas Nadeau; Harrison,N,Neil,DKQ7 R Cc: rco...@ptinovacao.pt; stbry...@cisco.com; m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard I think there is some confusion here The only CC in isolation in the draft is the option to use RFC 5885. Which then is a network design issue. Draft cc-cv-rdi used by itself is CV always on. It is just not EVERY PDU that requires CV processing so there are CC and CV PDUs interleaved. Mis-connectivity detection is network wide and fairly authoritative (unless we are discussing a mode of failure in which only some packets leak, which means even an always on CV may not be so unlucky as to leak and be detected). So I think we are in agreement on that front... Dave -Original Message- From: Thomas Nadeau [mailto:tnad...@lucidvision.com] Sent: Friday, July 08, 2011 8:27 AM To: neil.2.harri...@bt.com Cc: rco...@ptinovacao.pt; David Allan I; stbry...@cisco.com; m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard On Jul 8, 2011, at 3:15 AM, neil.2.harri...@bt.com wrote: Got to say I agree with Rui on much of what he says here. And I absolutely resonate with his point on the need for simplicity. The reason OAM needs to be as simple as possible is because it must be super reliablewe do not want to consciously build in weaknesses, esp unnecessary ones this also implies minimal config. We could all do better on this. For example: - Rui is dead right a CC function is fairly useless, we only need a CV function...the ATM OAM in I.610 suffers from this problem (and few others like AIS and the assumed use of request/response MLT to diagnose leaking/mismerging traffic...request/response OAM won't work with unidirectional defects). While you are entitled to your opinion, I personally think there are enough requirements elsewhere to have both CC and CV functions. But we digress. Are you actually asking that the CC functionality be removed from the draft or just making a general comment? - all packet layer networks should not have an AIS OAM messagevery obvious for the cl-ps mode of course. The co-ps mode is also not like the co-cs mode. One has to consciously manufacture AIS messages and target them to specific clients in the co-ps modewho may have taken action in their own layer network and 'moved elsewhere' anyway, ie a total waste of time now. AIS is actually unnecessary wrt providing information anyway, it simply represents an in-built weakness of just something else to go wrong which itself will create problems. What does that comment have to do with the actual draft in question? - creating preconfigured TCM sublayers is just asking for trouble IMO. It is far smarter to simply create a single end-end OAM CV (and when required PM) flow and tap this off at intermediate nodes on the *rare* occasions one wants to do. Again, what does this have to do with the actual draft in question? --tom regards, Neil This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above
RE: [mpls] 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
Excellent...well done Adrian! Thanks Dave for the info. Have a nice one yourself regards, Neil -Original Message- From: David Allan I [mailto:david.i.al...@ericsson.com] Sent: 08 July 2011 17:42 To: Harrison,N,Neil,DKQ7 R; tnad...@lucidvision.com Cc: rco...@ptinovacao.pt; stbry...@cisco.com; m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Hi Neil: As a result of Adrians AD review, some text to that effect was added to the Security Considerations section. Have a good weekend Dave -Original Message- From: neil.2.harri...@bt.com [mailto:neil.2.harri...@bt.com] Sent: Friday, July 08, 2011 9:40 AM To: David Allan I; tnad...@lucidvision.com Cc: rco...@ptinovacao.pt; stbry...@cisco.com; m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thanks Dave. If we don't have this (ie CV function on all connections/LSPs) then there is potential security risk wrt leaking traffic. Note that besides trad nested sublayered LSPs in the same layer network this also applies to nested LSPs belonging to different MPLS-TP layer networks (may be same or different party ownership). This point about the OAM CV function also ought to be captured in any security drafts. regards, Neil -Original Message- From: David Allan I [mailto:david.i.al...@ericsson.com] Sent: 08 July 2011 17:30 To: Thomas Nadeau; Harrison,N,Neil,DKQ7 R Cc: rco...@ptinovacao.pt; stbry...@cisco.com; m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard I think there is some confusion here The only CC in isolation in the draft is the option to use RFC 5885. Which then is a network design issue. Draft cc-cv-rdi used by itself is CV always on. It is just not EVERY PDU that requires CV processing so there are CC and CV PDUs interleaved. Mis-connectivity detection is network wide and fairly authoritative (unless we are discussing a mode of failure in which only some packets leak, which means even an always on CV may not be so unlucky as to leak and be detected). So I think we are in agreement on that front... Dave -Original Message- From: Thomas Nadeau [mailto:tnad...@lucidvision.com] Sent: Friday, July 08, 2011 8:27 AM To: neil.2.harri...@bt.com Cc: rco...@ptinovacao.pt; David Allan I; stbry...@cisco.com; m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard On Jul 8, 2011, at 3:15 AM, neil.2.harri...@bt.com wrote: Got to say I agree with Rui on much of what he says here. And I absolutely resonate with his point on the need for simplicity. The reason OAM needs to be as simple as possible is because it must be super reliablewe do not want to consciously build in weaknesses, esp unnecessary ones this also implies minimal config. We could all do better on this. For example: - Rui is dead right a CC function is fairly useless, we only need a CV function...the ATM OAM in I.610 suffers from this problem (and few others like AIS and the assumed use of request/response MLT to diagnose leaking/mismerging traffic...request/response OAM won't work with unidirectional defects). While you are entitled to your opinion, I personally think there are enough requirements elsewhere to have both CC and CV functions. But we digress. Are you actually asking that the CC functionality be removed from the draft or just making a general comment? - all packet layer networks should not have an AIS OAM messagevery obvious for the cl-ps mode of course. The co-ps mode is also not like the co-cs mode. One has to consciously manufacture AIS messages and target them to specific clients in the co-ps modewho may have taken action in their own layer network and 'moved elsewhere' anyway, ie a total waste of time now. AIS is actually unnecessary wrt providing information anyway, it simply represents an in-built weakness of just something else to go wrong which itself will create problems. What does that comment have to do with the actual draft in question? - creating preconfigured TCM sublayers is just asking for trouble IMO
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
Neil, I have a question for clarification. Have you actually read draft-ietf-mpls-tp-cc-cv-rdi-05.txt? I know you don't like doing this but generally it is considered good form to read something before commenting on it. Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of neil.2.harri...@bt.com Sent: Friday, July 08, 2011 12:16 AM To: rco...@ptinovacao.pt; david.i.al...@ericsson.com; stbry...@cisco.com Cc: m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Got to say I agree with Rui on much of what he says here. And I absolutely resonate with his point on the need for simplicity. The reason OAM needs to be as simple as possible is because it must be super reliablewe do not want to consciously build in weaknesses, esp unnecessary ones this also implies minimal config. We could all do better on this. For example: - Rui is dead right a CC function is fairly useless, we only need a CV function...the ATM OAM in I.610 suffers from this problem (and few others like AIS and the assumed use of request/response MLT to diagnose leaking/mismerging traffic...request/response OAM won't work with unidirectional defects). - all packet layer networks should not have an AIS OAM messagevery obvious for the cl-ps mode of course. The co-ps mode is also not like the co-cs mode. One has to consciously manufacture AIS messages and target them to specific clients in the co-ps modewho may have taken action in their own layer network and 'moved elsewhere' anyway, ie a total waste of time now. AIS is actually unnecessary wrt providing information anyway, it simply represents an in-built weakness of just something else to go wrong which itself will create problems. - creating preconfigured TCM sublayers is just asking for trouble IMO. It is far smarter to simply create a single end-end OAM CV (and when required PM) flow and tap this off at intermediate nodes on the *rare* occasions one wants to do. regards, Neil This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 180 -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Rui Costa Sent: 08 July 2011 01:15 To: David Allan I; Stewart Bryant Cc: ietf@ietf.org; IETF-Announce; m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard David, Reading something, keeping it on record, without effect in the draft and ignoring comments have IMHO similar outcomes. As author of the draft you are free to do it. These standards have a great impact in our work, so i'm also free to write what i did. Stewart, My technical concerns regarding this draft were expressed... ...in the (ITU-T - IETF, Feb/2011) liaison regarding it (LS281, i believe); ...in operators' meetings' that took place during ITU-T's Feb/2011 plenary meeting; ...in a comparison session that took place during that same ITU-T meeting. Some: CC/CV I don't understand the need for 2 types of packets: a single type allows CC; mismatching identifiers in the same CC packets allow CV. Besides adding complexity, we whether always activate both or potentiate undetected mismerges. (BTW: can't understand how we propose one ACH codepoint to CC, another for CV, [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
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
Got to say I agree with Rui on much of what he says here. And I absolutely resonate with his point on the need for simplicity. The reason OAM needs to be as simple as possible is because it must be super reliablewe do not want to consciously build in weaknesses, esp unnecessary ones this also implies minimal config. We could all do better on this. For example: - Rui is dead right a CC function is fairly useless, we only need a CV function...the ATM OAM in I.610 suffers from this problem (and few others like AIS and the assumed use of request/response MLT to diagnose leaking/mismerging traffic...request/response OAM won't work with unidirectional defects). - all packet layer networks should not have an AIS OAM messagevery obvious for the cl-ps mode of course. The co-ps mode is also not like the co-cs mode. One has to consciously manufacture AIS messages and target them to specific clients in the co-ps modewho may have taken action in their own layer network and 'moved elsewhere' anyway, ie a total waste of time now. AIS is actually unnecessary wrt providing information anyway, it simply represents an in-built weakness of just something else to go wrong which itself will create problems. - creating preconfigured TCM sublayers is just asking for trouble IMO. It is far smarter to simply create a single end-end OAM CV (and when required PM) flow and tap this off at intermediate nodes on the *rare* occasions one wants to do. regards, Neil This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 180 -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Rui Costa Sent: 08 July 2011 01:15 To: David Allan I; Stewart Bryant Cc: ietf@ietf.org; IETF-Announce; m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard David, Reading something, keeping it on record, without effect in the draft and ignoring comments have IMHO similar outcomes. As author of the draft you are free to do it. These standards have a great impact in our work, so i'm also free to write what i did. Stewart, My technical concerns regarding this draft were expressed... ...in the (ITU-T - IETF, Feb/2011) liaison regarding it (LS281, i believe); ...in operators' meetings' that took place during ITU-T's Feb/2011 plenary meeting; ...in a comparison session that took place during that same ITU-T meeting. Some: CC/CV I don't understand the need for 2 types of packets: a single type allows CC; mismatching identifiers in the same CC packets allow CV. Besides adding complexity, we whether always activate both or potentiate undetected mismerges. (BTW: can't understand how we propose one ACH codepoint to CC, another for CV, [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
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
Not recently John. But my comments are general and not specific to this draft. But it seems you are implying that the draft recognises my points. If so I will look forward to reading it later today when I get chance and seeing AIS deprecated, TCM deprecated, CC functions deprecated, ability to tap off end-end CV/PM flows at intermediate nodes. regards, Neil This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 180 -Original Message- From: John E Drake [mailto:jdr...@juniper.net] Sent: 08 July 2011 14:26 To: Harrison,N,Neil,DKQ7 R; rco...@ptinovacao.pt; david.i.al...@ericsson.com; stbry...@cisco.com Cc: m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Neil, I have a question for clarification. Have you actually read draft- ietf-mpls-tp-cc-cv-rdi-05.txt? I know you don't like doing this but generally it is considered good form to read something before commenting on it. Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of neil.2.harri...@bt.com Sent: Friday, July 08, 2011 12:16 AM To: rco...@ptinovacao.pt; david.i.al...@ericsson.com; stbry...@cisco.com Cc: m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Got to say I agree with Rui on much of what he says here. And I absolutely resonate with his point on the need for simplicity. The reason OAM needs to be as simple as possible is because it must be super reliablewe do not want to consciously build in weaknesses, esp unnecessary ones this also implies minimal config. We could all do better on this. For example: - Rui is dead right a CC function is fairly useless, we only need a CV function...the ATM OAM in I.610 suffers from this problem (and few others like AIS and the assumed use of request/response MLT to diagnose leaking/mismerging traffic...request/response OAM won't work with unidirectional defects). - all packet layer networks should not have an AIS OAM messagevery obvious for the cl-ps mode of course. The co-ps mode is also not like the co-cs mode. One has to consciously manufacture AIS messages and target them to specific clients in the co-ps modewho may have taken action in their own layer network and 'moved elsewhere' anyway, ie a total waste of time now. AIS is actually unnecessary wrt providing information anyway, it simply represents an in-built weakness of just something else to go wrong which itself will create problems. - creating preconfigured TCM sublayers is just asking for trouble IMO. It is far smarter to simply create a single end-end OAM CV (and when required PM) flow and tap this off at intermediate nodes on the *rare* occasions one wants to do. regards, Neil This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 180 -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Rui Costa Sent: 08 July 2011 01:15 To: David Allan I; Stewart Bryant Cc: ietf@ietf.org; IETF-Announce; m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi- 05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard David, Reading something, keeping it on record, without effect in the draft and ignoring comments have IMHO similar outcomes. As author of the draft you are free to do it. These standards have a great impact
