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
