Subject: [mpls] FW: New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 13 Jun 2014 21:14:43 +0000

Dear MPLS WG,

On MPLS data plane, one aspect which OAM is blind to traffic black holing is when LSPs are traversing over LAG interfaces. We would like to propose an extension to RFC4379 to provide the tool an ability to discover and traverse LAG members.

It will be very helpful if you could review this document, provide comments and help us standardize this extension.

Thanks!

-Nobo, on behalf of authors

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, June 13, 2014 5:04 PM
> To: John E. Drake; Nobo Akiya (nobo); George Swallow (swallow); George
> Swallow (swallow); Bruno Decraene; Stephane Litkowski; Bruno Decraene;
> Nobo Akiya (nobo); John Drake; Stephane Litkowski
> Subject: New Version Notification for draft-akiya-mpls-lsp-ping-lag-
> multipath-00.txt
> 
> 
> A new version of I-D, draft-akiya-mpls-lsp-ping-lag-multipath-00.txt
> has been successfully submitted by Nobo Akiya and posted to the IETF
> repository.
> 
> Name:		draft-akiya-mpls-lsp-ping-lag-multipath
> Revision:	00
> Title:		Label Switched Path (LSP) Ping/Trace Multipath Support for
> Link Aggregation Group (LAG) Interfaces
> Document date:	2014-06-13
> Group:		Individual Submission
> Pages:		18
> URL:            http://www.ietf.org/internet-drafts/draft-akiya-mpls-lsp-ping-
> lag-multipath-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-lag-
> multipath/
> Htmlized:       http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-lag-
> multipath-00
> 
> 
> Abstract:
>    This document defines an extension to the Multiprotocol Label
>    Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute to
>    describe Multipath Information for Link Aggregation (LAG) member
>    links separately, thus allowing MPLS LSP Ping and Traceroute to
>    discover and exercise specific paths of layer 2 Equal-Cost Multipath
>    (ECMP) over LAG interfaces.
> 
>    This document updates RFC4379 and RFC6424.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 22 Jun 2014 15:43:05 +0000

Hi Nagendra,

> From: Nagendra Kumar Nainar (naikumar)
> Sent: Saturday, June 14, 2014 1:54 PM
> To: Nobo Akiya (nobo)
> Subject: Re: New Version Notification for draft-akiya-mpls-lsp-ping-lag-
> multipath-00.txt
> 
> Hi Nobo,
> 
> As usual, interesting draft. Please see below for initial comments,

Thank you for comments, and thank you for agreeing to allow me to include the MPLS WG in this response.

I'm glad you found this document to be interesting. Although it became a bit more complicated that I was originally hoping. However, this extension add a great value to a tool which can be part of the something larger to "fight" the traffic black hole happening on MPLS networks :)
 
> 
> From section 3, It appears that responder MUST set the LAG Info TLV. Is it the
> case even if the downstream is not LAG?. Or did you meant that if the
> responder have LAG based donwstream interface, then it MUST include the
> TLV?.

First bullet in the last portion of the Section 3 was exactly to explain why this is a MUST, but clearly additional text will be helpful. How about we update the bullet:

[old]
   o  Identify whether responder LSR understands this mechanism.

[new]
   o  Mandating the responder to always add the LAG Interface Info TLV
      in the MPLS echo reply allows the initiating LSR to identify
      whether responder LSR understands this mechanism.

> 
> 
> In Section, I am trying to understand what does the below means,
> 
> "All fields and Sub-TLVs, except for Multipath Data Sub-TLV and
>          Interface Index Sub-TLV, are set/added to DDMAP to describe
>          this LAG interface, as per [RFC6424].
> "
> 
> The above statement followed by statement to add "Interface Index Sub-
> TLV"
> appears to be confusing.

I see. Perhaps re-wording it can help clarify things. How about something like this?

[old]
      *  All fields and Sub-TLVs, except for Multipath Data Sub-TLV and
         Interface Index Sub-TLV, are set/added to DDMAP to describe
         this LAG interface, as per [RFC6424].

[new]
      *  In the DDMAP, Multipath Data Sub-TLV and Interface Index Sub-
         TLV are to describe each LAG member link.  All other fields of
         the DDMAP are to describe the LAG interface.

> 
> 
> In section 3, the below 2 statements appears to be redundant. Do we really
> need both?.
> 
> "*  For each LAG member link of this LAG interface:
> 
>          +  MUST add Interface Index Sub-TLV (described in Section 7)
>             with LAG Member Link Indicator flag set in Interface Index
>             Flags, describing this LAG member link.
> 
>          +  MUST add Multipath Data Sub-TLV for this LAG member link, if
>             received DDMAP requested multipath information.
> 
>    Each LAG member link is described with Interface Index Sub-TLV and
>    conditionally with Multipath Data Sub-TLV (if multipath information
>    is requested). "

True. Let me re-word this one too.

[old]
   Each LAG member link is described with Interface Index Sub-TLV and
   conditionally with Multipath Data Sub-TLV (if multipath information
   is requested).  If both Sub-TLVs are placed in the DDMAP to describe
   a LAG member link, Interface Index Sub-TLV MUST be added first with
   Multipath Data Sub-TLV immediately following.

[new]
   When both the Interface Index Sub-TLV and the Multipath Data Sub-TLV
   is placed in the DDMAP to describe a LAG member link, Interface Index
   Sub-TLV MUST be added first with Multipath Data Sub-TLV immediately
   following.

> 
> 
> Section 4 says the inclusion of Detailed interface TLV is a MUST while
> section 8 sys it is a MAY statement as below,
> 
> section 4:
> "
> Responder LSR MUST:
> 
>    o  Add LAG Interface Info TLV in the MPLS echo reply to provide
>       acknowledgement back to the initiator.  Upstream LAG Info
>       Accommodation flag MUST be set in LAG Interface Info Flags.
> 
>    o  Add the Detailed Interface and Label Stack TLV (described in
>       Section 8) in the MPLS echo reply.
> "
> 
> section 8:
> "The Detailed Interface and Label Stack object is a TLV that MAY be
>    included in a MPLS echo reply message to report the interface on
>    which the MPLS echo request message was received and the label stack
>    that was on the packet when it was received.  A responder LSR MUST
>    NOT insert more than one instance of this TLV. "
> 

Right, perhaps above snippet being preceded by the initiating LSR sending the MPLS echo request with DS Flags I bit set is not sufficient to elude that responder is functioning with an assumption that it needs to include interface/label-stack TLV. Let me change some texts:

[old]
   o  Add the Detailed Interface and Label Stack TLV (described in
      Section 8) in the MPLS echo reply.

   o  Add the Incoming Interface Index Sub-TLV (described in
      Section 8.1.2) for LAG interfaces.  The LAG Member Link Indicator
      flag MUST be set in Interface Index Flags, and the incoming
      Interface Index set to LAG member link which received the MPLS
      echo request.

[new]
   o  When the received DDMAP had DS Flags I set, add the Detailed
      Interface and Label Stack TLV (described in Section 8) in the MPLS
      echo reply.

   o  When the received DDMAP had DS Flags I set, add the Incoming
      Interface Index Sub-TLV (described in Section 8.1.2) for LAG
      interfaces.  The LAG Member Link Indicator flag MUST be set in
      Interface Index Flags, and the incoming Interface Index set to LAG
      member link which received the MPLS echo request.

> 
> 
> Section 7 specifies as below,
> "The Interface Index Sub-TLV describes the index assigned by the
>    upstream LSR to the interface."
> 
> Can you also point some reference to what type of index is it?. Is it
> something assigned and advertised by LAG protocol like LACP or PAGP?.

It's a locally allocated persistent index for local interfaces. It may or may not be advertised, and that's not really important for this context. We are just interested in getting a unique value (local to that node) that identifies a specific interface. I could add more texts, but the description on this sub-TLV was mostly ported from RFC4379. I think it's ok as is.

> 
> In association to above, Section 4 states the below,
> 
> "Note that defined procedures will provide a deterministic result for
>    LAG interfaces that are back-to-back connected between routers (i.e.
>    no L2 switch in between).  If there is a L2 switch between LSR at
>    TTL=n and LSR at TTL=n+1, there is no guarantee that traversal of
>    every LAG member link at TTL=n will result in reaching different
>    interface index at TTL=n+1."
> 
> When there is L2 switch(es) in between, the LAG termination/negotiation
> wil be between the LSR and L2 switch and so we may need some way to
> exchange the Interface Index for each LAG member via L2 switch to be
> exchanged between the LSRs. I am not aware of such exchange. If I am
> missing something, I think it is worth referring the same for clarity :)

That is exactly why L2-in-between is outside the scope of this document :) Appendix A describes various flavors and why it is complicated to extend support for those flavors.

> 
> Does the below sounds like a (direct) SHOULD statement?
> 
> "If the responder LSR is able to accommodate this request,
>    then the LAG Interface Info object MUST be included in the MPLS echo
>    reply message."
> 
> In the below topology,
> 
>         +-------+
>              |       |
>      A-------B=======C-------E
>              |       |       |
>              +-------D-------G
> 
> Assume A is validating all ECMP paths from A to G. Assume the metric from
> B to D is 2 and rest all link are 1. So it will be
> 
> A-B-LAG-C-E-G
> A-B-LAG-C-D-G
> A-B-D-G
> 
> Assume the list of multipath data is (1-10)
> 
> Now B will reply as below,
> 
> (1,2,3) - {Link1, Downstream:C}
> (4,5,6) - {Link2 Downstream:C}
> (7,8,9,10) - {LinkBC, Downstream:D}
> 
> A will then send 2 request as below:
> 
> Echo1 (to C) - (multipath:1,2,3,4,5,6),
> Echo2 (to D) - (multipath:7,8,9,10)
> 
> C will reply back with
> 
> (1,2,3) - {LinkCE, Downstream E}
> (4,5,6) - {LinkCD, Downstream D}
> 
> So we dont have anything common between Link2 of LAG and downtream E.
> Similarly we dont have anyhting common between Link1 of LAG and
> downstream D (from C). I think we need the downstream node of LAG to
> reply back with multipath info for each downstream from each LAG range.
> Any thoughts?.

The main problem with above example is that the range of multipath info is too small, thus you ran out of intersect in the downstream. Additionally, if I was to implement this, then I would not carry over treating each LAG member link separately in the LSP Tree Trace operations, once TTL=n+1 is reached. Once LAG merges to a same downstream node, then I would aggregate the result and move forward in the downstream (i.e. treat the LAG as one logical interface).

Thanks!

-Nobo

> 
> Thanks,
> Nagendra
> 
> 
> 
> 
> On 6/13/14, 5:33 PM, "Nobo Akiya (nobo)" <[email-masked]> wrote:
> 
> >FYI, new LSP Ping extension draft.
> >
> >> From: mpls [mailto:[email-masked]] On Behalf Of Nobo Akiya
> >> (nobo)
> >> Sent: Friday, June 13, 2014 5:15 PM
> >> To: [email-masked]
> >> Subject: [mpls] FW: New Version Notification for
> >>draft-akiya-mpls-lsp-ping-
> >> lag-multipath-00.txt
> >>
> >> Dear MPLS WG,
> >>
> >> On MPLS data plane, one aspect which OAM is blind to traffic black
> >>holing is  when LSPs are traversing over LAG interfaces. We would like
> >>to propose an  extension to RFC4379 to provide the tool an ability to
> >>discover and traverse  LAG members.
> >>
> >> It will be very helpful if you could review this document, provide
> >>comments  and help us standardize this extension.
> >>
> >> Thanks!
> >>
> >> > To: John E. Drake; Nobo Akiya (nobo); George Swallow (swallow);
> >> > George Swallow (swallow); Bruno Decraene; Stephane Litkowski; Bruno
> >> > Decraene; Nobo Akiya (nobo); John Drake; Stephane Litkowski
> >> > Subject: New Version Notification for
> >> > draft-akiya-mpls-lsp-ping-lag- multipath-00.txt
> >> >
> >> >
> >> > A new version of I-D,
> >> > draft-akiya-mpls-lsp-ping-lag-multipath-00.txt
> >> > has been successfully submitted by Nobo Akiya and posted to the
> >> > IETF repository.
> >> >
> >> > URL:
> >>http://www.ietf.org/internet-drafts/draft-akiya-mpls-lsp-ping-
> >> > lag-multipath-00.txt
> >> > Status:
> >>https://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-lag-
> >> > multipath/
> >> > Htmlized:
> >>http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-lag-
> >> > multipath-00
> >> >
> >> >
> >> > Abstract:
> >> _______________________________________________
> >> mpls mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/mpls