Re: [mpls] MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping

["Carlos Pignataro (cpignata)" <[e-mail]>]

Loa,

Regarding the new registry, the most sensible thing is the smack document
‹ however, from a timing perspective it might not. Either way should be
fine, and yet another alternative is to pull out the LSP Ping IANA
considerations outside into its own doc.

Thanks,

Carlos.

-----Original Message-----
From: Loa Andersson <[e-mail]>
Date: Sunday, September 27, 2015 at 4:00 AM
To: "Dutta, Pranjal K (Pranjal)" <[e-mail]>,
Curtis Villamizar <[e-mail]>, Vishwas Manral
<[e-mail]>, Lizhong Jin <[e-mail]>,
"[e-mail]"
<[e-mail]>,
"[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping
Resent-From: Loa Andersson <[e-mail]>
Resent-To: <[e-mail]>,
<[e-mail]>
Resent-Date: Sunday, September 27, 2015 at 4:01 AM

>Authors,
>
>We now have three MPLS-RT reviews. Please feel free to go ahead
>and consider the comments and to the updates you think is necessary.
>
>As you do so close the loop with the authors and make sure they are
>comfortable to go forward to the wg adoption poll.
>
>I personal twist on this that I learnt that the comments you address
>now the easier it is too get through the adoption poll.
>
>Carlos,
>
>About the new registry, think about where you want to define it, here
>or in smack (if there were no timing issues I'd say smack).
>
>/Loa
>mpls wg co-chair
>
>On 2015-09-26 08:58, Dutta, Pranjal K (Pranjal) wrote:
>> Hi,
>>
>>     I have been asked by the WG chairs for MPLS-RT review on this draft.
>> I have reviewed the version
>> https://tools.ietf.org/html/draft-kumarkini-mpls-spring-lsp-ping-04 and
>> following are my review comments.
>>
>> 1.Section 4.1 on the problem definition: This section falls short of
>> discussing various critical fault scenarios in detail.
>>
>> For example, following is an important case.
>>
>>                    +--------+
>>
>>                    |   L2   |
>>
>>                    R3-------R6
>>
>>                   /           \
>>
>>                  /             \
>>
>>          R1----R2               R7----R8
>>
>>                  \             /
>>
>>                   \           /
>>
>>                    R4-------R5
>>
>>      9136 --> Adjacency Segment ID from R3 to R6 over link L1.
>>
>>      9236 --> Adjacency Segment ID from R3 to R6 over link L2.
>>
>>      9124 --> Adjacency segment ID from R2 to R4.
>>
>>      9123 --> Adjacency Segment ID from R2 to R3.
>>
>>      9145 --> Adjacency Segment ID from R4 to R5.
>>
>>      9157 --> Adjacency segment ID from R5 to R7.
>>
>>      9178 --> Adjacency segment ID from R7 to R8.
>>
>>      9167 --> Adjacency segment ID from R6 to R7.
>>
>> Let's say R1 originates a packet with the following label stack:
>>
>>     9123 + 9136 + 9167 + 9178 + Payload
>>
>>     R2 pops Adjacency Segment ID 9123 and forwards the packet to the
>> correct next-hop link R2-R3. But R2 is malfunctioning such that it also
>> pops 9136.
>>
>>     Thus R3 receives the Adjacency Segment ID 9167. By quirk of fate
>> Label/9167 = label/9236 because both labels are locally significant to
>> advertising nodes.
>>
>>     As a result, R3 forwards the packet to R6 over link L2. R6 receives
>> 9178 and drops the packet after finding no state programmed for 9178.
>> The packet
>>
>>     traverses the intended path till R6 whereas the problem is at R2.
>>
>>     Similarly, instead of POPPing unwanted labels the malfunctioning
>> node could PUSH unwanted labels. Such issues may not be due to wrong
>> programming by control plane (or data
>>     plane out of sync) and can happen due to a few bit flips on faulty
>> h/w or memory.
>>
>> 2.Sections 5.1 and 5.2: the target FEC stack TLV for a prefix SID MUST
>> include the SID index value and not just the address to be sure this
>> gets checked for overlaps or errors of assigning the SID index value.
>>
>> 3.Section 6: The DSMAP should not be supported with SR and SR-TE LSP.
>> The DDMAP is required because of the hierarchical nature of the LSP. See
>> next comment for more details.
>>
>> 4.Section 7.1: I think what is missing upfront in the document is the
>> modeling in MPLS OAM of a SR or SR-TE LSP. Basically, it should be
>> modeled as a hierarchical LSP which MUST use the DDMAP TLV with the FEC
>> Stack Change sub-TLV to operate correctly. The following operations are
>> supported:
>>
>> a.A node/prefix SID label that is swapped at an LSR results in the
>> normal return code of 8  "Label switched at stack-depth <RSC>" as per
>> RFC 4379.
>>
>> b.A node/prefix SID label which is popped at an LSR results in a FEC
>> stack change TLV operation of ³POP² as per RFC 6424.
>>
>> c.An adjacency SID label popped at an LSR results in a FEC stack change
>> TLV operation of ³POP² as per RFC 6424. In other words, we are modeling
>> the swap operation into a implicit NULL label as a POP to simplify the
>> tracing operation with DDMAP.
>>
>> 5.Section 7.1: The text under paragraph titled ³Traceroute² is very
>> ambiguous and confusing and it may suggest that new behavior is being
>> described. In fact, there is nothing new to add here and the behavior of
>> the FEC stack change sub-TLV is as per RFC 6424. All what is needed is a
>> clear description of the modeling of the SR/SR-TE LSP as per comment
>>above.
>>
>> For example, let's apply the procedures in this section to the fault
>> scenario I had discussed in comment 1).
>>
>>    5.1. R1 initiates Echo Request with TTL=1 carrying Targeted FEC stack
>> 9123 + 9136 + 9167 + 9178. From the procedures it is not clear  whether
>> R1 would send DSMAP/DDMAP TLV
>>           containing the Label stack. IMO, it MUST send Label stack -
>> without it R2 can't validate if received data plane label stack is same
>> as in received DSMAP/DDMAP (see later in 5.5).
>>
>>    5.2  R2 responds with Echo reply containing FEC stack change/pop for
>> 9123.
>>
>>    5.3. R1 initiates Echo Request with TTL=2 carrying Targeted FEC stack
>> 9136 + 9167 + 9178 and DSMAP/DDMAP containing corresponding label stack
>>
>>         9136 + 9167 + 9178. The data plane label stack is 9123 + 9136 +
>> 9167 + 9178.
>>
>>    5.4. The malfunctioning node R2 forwards the packet to R3 with
>> data-plane label stack 9167 + 9178.
>>
>>    5.5. R3 validates from received Targeted FEC stack that 9136 is the
>> indeed an advertised Adjacency ID and corresponding label in DSMAP/DDMAP
>> is correct. However the label stack
>>            received in data plane does not correspond to the label stack
>> in DSMAP - this is a key point and there is no mention of it in the
>> draft. Thus R3 responds with label_stack_validation
>>           failure which indicates a data plane fault in R2.
>>
>> 6.Section 7.2: the popping of the adjacency SID label is performed by
>> the node which assigned it and it is this node which generates the FEC
>> stack change sub-TLV with the operation of POP.
>>
>> 7.Section 7.3: while I agree that the implicit NULL label value for the
>> adjacency SID should not be used because the downstream LSR has no
>> context for the adjacency SID of his upstream neighbor (adjacency SIDs
>> are locally significant only) but for node SID with PHP, the downstream
>> node has context and actually signaled PHP flag in the prefix SID
>> sub-TLV. Implicit-Null value is thus valid for node SID.
>>
>> 8.Section 7.4: This section needs to be written to cover the cases of
>> regular swapping of node/prefix SID and the popping of node SID or
>> adjacency SID when receiving the FEC stack change sub-TLV. Also, what is
>> exactly ³Best return code to 10²?
>>
>> 9.Section 7.5: I do not think this section belongs here. If there are
>> recommendations for TTL setting for hierarchical LSPs, they sure are not
>> specific to SR/SR-TE LSP.
>>
>> 10.In Section 5
>>
>> ³Three new sub-TLVs are defined for TLVs type 1, 16 and 21.²
>>
>> It is not clear what is meant by TLVs type 1,16 and 21. Suggest to make
>> explicit references.
>>
>> 11. One missing point in MPLS-OAM so far is to let the originator of a
>> Traceroute know that responding node is currently exercising FRR backup
>> next-hop (because primary has failed).
>>       AFAIK, this is not covered in any MPLS OAM extensions so far. It
>> is good to address this in SR context.
>>
>> Summary
>>
>> -------------
>>
>> 1) Whether the document is coherent
>>
>>    - Yes
>>
>> 2) is it useful (i.e, is it likely to be actually useful in operational
>> networks)
>>
>>    - Yes
>>
>> 3) Is the document technically sound?
>>
>>    - Need precise modeling of MPLS-OAM of a SR/SR-TE LSP. Need to
>> precisely describe procedures in the context of  SR/SR-TE LSP and
>> applicability of RFC 4379, 6424.
>>
>> 4) Whether the document is ready to be considered for WG adoption
>>
>>    - It is a good start but I would like to see the concerns addressed
>> before publishing the WG draft.
>>
>> Thanks,
>>
>> Pranjal
>>
>> -----Original Message-----
>> From: Loa Andersson [mailto:[e-mail]]
>> Sent: Wednesday, September 09, 2015 3:00 AM
>> To: Curtis Villamizar; [e-mail]; Dutta, Pranjal K
>> (Pranjal); Lizhong Jin;
>> [e-mail];
>> [e-mail]
>> Subject: Fwd: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping
>>
>> Resending, Vishwas mail bounced and forgot to include the authors and my
>> co-chairs.
>>
>> /Loa
>>
>> Curtis, Vishwas, Pranjal, and Lizhong,
>>
>> You have be selected as MPLS-RT reviewers for draft-kumarkini-
>> mpls-spring-lsp-ping.
>>
>> Note to authors: You have been CC'd on this email so that you can know
>> that this review is going on. However, please do not review your own
>> document.
>>
>> Reviews should comment on whether the document is coherent, is it useful
>> (ie, is it likely to be actually useful in operational networks), and is
>> the document technically sound?
>>
>> We are interested in knowing whether the document is ready to be
>> considered for WG adoption (ie, it doesn't have to be perfect at this
>> point, but should be a good start).
>>
>> Reviews should be sent to the document authors, WG co-chairs and WG
>> secretary, and CC'd to the MPLS WG email list. If necessary, comments
>> may be sent privately to only the WG chairs.
>>
>> If you have technical comments you should try to be explicit about what
>> needs to be resolved before adopting it as a working group document, and
>> what can wait until the document is a working group document and the
>> working group has the revision control.
>>
>> Are you able to review this draft by September 25, 2015? Please respond
>> in a timely fashion.
>>
>> Thanks, Loa
>>
>> (as MPLS WG chair)
>>
>> --
>>
>> Loa Andersson                        email: [e-mail]
>> <mailto:[e-mail]>
>>
>> Senior MPLS Expert [e-mail] <mailto:[e-mail]>
>>
>> Huawei Technologies (consultant)     phone: [phone]
>>
>> --
>>
>> Loa Andersson                        email: [e-mail]
>> <mailto:[e-mail]>
>>
>> Senior MPLS Expert [e-mail] <mailto:[e-mail]>
>>
>> Huawei Technologies (consultant)     phone: [phone]
>>