RE: [mpls] Last Call: <draft-ietf-mpls-tp-on-demand-cv-06.txt> (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Zhenlong Cui
Sent: Thursday, August 25, 2011 2:17 AM
To: ietf@ietf.org; 'IETF-Announce'
Cc: mpls@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-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The IESG
> Sent: Thursday, August 11, 2011 10:46 PM
> To: IETF-Announce
> Cc: mpls@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 iesg@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
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls@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


[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux