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

[Loa Andersson <[e-mail]>]

Carlos,

I've another option, how about writing a short draft that does nothing
but define the new registry. We progress it ahead of the other two
drafts. When we get to this point in smack we pull it in as any other
"old" draft.

/Loa

On 2015-09-28 02:43, Carlos Pignataro (cpignata) wrote:
> 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]
>>>
>