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-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Eric Gray
Sent: Sunday, September 04, 2011 11:35 PM
To: Yoshinori Koike; ietf(_at_)ietf(_dot_)org
Cc: mpls(_at_)ietf(_dot_)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-bounces(_at_)ietf(_dot_)org
[mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of Yoshinori Koike
Sent: Thursday, August 25, 2011 12:35 PM
To: ietf(_at_)ietf(_dot_)org
Cc: mpls(_at_)ietf(_dot_)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-bounces(_at_)ietf(_dot_)org
[mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of The IESG
Sent: Thursday, August 11, 2011 10:46 PM
To: IETF-Announce
Cc: mpls(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org mailing lists by 2011-08-25. Exceptionally,
comments may be
sent to iesg(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls
--
_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf