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

["Nagendra Kumar Nainar (naikumar)" <[e-mail]>]

Hi Pranjal,

Thanks for the review and comments. We will address the same and will update back.

Thanks,
Nagendra

From: <Dutta>, "Pranjal K (Pranjal)" <[e-mail]<mailto:[e-mail]>>
Date: Friday, September 25, 2015 at 8:58 PM
To: Loa Andersson <[e-mail]<mailto:[e-mail]>>, Curtis Villamizar <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Lizhong Jin <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-Date: Friday, September 25, 2015 at 8:58 PM


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]<mailto:[e-mail]>; Dutta, Pranjal K (Pranjal); Lizhong Jin; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]