Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-on-demand-cv-06.txt> (MPLS On-demand Connectivity Verification and Route Tracing) to Proposed Standard

From: Rolf Winter <[email-masked]>
Date: Thu, 18 Aug 2011 06:58:13 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> The IESG
> Sent: Donnerstag, 11. August 2011 15:46
> To: IETF-Announce
> Cc: [email-masked]
> 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
> [email-masked] mailing lists by 2011-08-25. Exceptionally, comments may
> be
> sent to [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Mach Chen <[email-masked]>
Date: Fri, 19 Aug 2011 09:50:12 +0000

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of The
> IESG
> Sent: Thursday, August 11, 2011 9:46 PM
> To: IETF-Announce
> Cc: [email-masked]
> 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
> [email-masked] mailing lists by 2011-08-25. Exceptionally, comments may be
>    Transport Profile (MPLS-TP) LSPs and Pseudowires.  This document also
>    MPLS-TP networks.  Finally this document updates RFC 4379 by adding a

---

From: venkatesan mahalingam <[email-masked]>
Date: Sun, 21 Aug 2011 13:48:04 -0400

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.

---

From: venkatesan mahalingam <[email-masked]>
Date: Sun, 21 Aug 2011 14:57:47 -0400

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:[email-masked]?subject=help>
List-id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www.ietf.org/mailman/listinfo/mpls>,
<mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/options/mpls>,
<mailto:[email-masked]?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

---

From: Yoshinori Koike <[email-masked]>
Date: Fri, 26 Aug 2011 01:34:54 +0900

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
>
>
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of The IESG
>> Sent: Thursday, August 11, 2011 10:46 PM
>> To: IETF-Announce
>> Cc: [email-masked]
>> Subject: [mpls] Last Call:<draft-ietf-mpls-tp-on-demand-cv-06.txt>  (MPLSOn-demand Connectivity Verification and Route
>> Tracing) toProposed Standard
>>
>>

--

---

From: "Zhenlong Cui" <[email-masked]>
Date: Thu, 25 Aug 2011 15:17:10 +0900

Hi,

Best regards,
zhenlong

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