[mpls] Review of draft-kumarkini-mpls-string-lsp-ping

[Rob Shakir <[e-mail]>]

Hi MPLS WG & draft authors,

Thanks for the work on this draft -- having working OAM functions in a 
SR network using the MPLS data plane is definitely something that I 
think is needed - and if (of course) seems a good plan to extend the 
existing RFC4379 mechanisms to work with SR.

Generally, I think the document defines what it needs to - but there are 
a few technical issues and/or clarifications of concepts that I think 
are required to make this robust and implementable. A few of them seem 
to stem from changes that have been made to the SR architecture and 
MPLS-SR dataplane documents as they have made it through the SPRING 
working group.

I've laid out some of my specific questions/comments below:

  * Introduction:
      o References to draft-filsfils-rtgwg-segment-routing are outdated
        - these should be updated to reflect the SPRING WG's segment
        routing architecture I-D: draft-ietf-spring-segment-routing.
      o I suspect that it will also be advantageous for this draft to
        reference draft-ietf-spring-segment-routing-mpls - to provide
        the reader with information as to how the segment routing
        architecture is implemented in MPLS.
      o In this section  there is a reference to "segment assignment ...
        not [being on a] hop-by-hop- basis"  - this is quite an
        ambiguous statement (consider adjacency segments, these are
        locally assigned by the originating LSR - and do not have any
        meaning outside of this particular LSR's LFIB). Additionally
        where a prefix SID is generated, then the current format that
        the IGP solutions drafts provide gives a means to do this via an
        index which then allows the label to be allocated (in this case
        the use of the term 'segment' makes it unclear whether we are
        talking about a SID or a label). From my reading, the intention
        here to express that in the SR architecture it is possible
        (where two nodes are configured with the same SRGB) that a
        particular segment identifier (particularly an IGP Prefix SID)
        may be correctly forwarded according to the FEC Stack TLV, even
        though the intended path was not taken. If this is what the
        sentence is trying convey, which I think it is, based on the
        discussion in Section 3.1, then it'd be good if this could be
        explicitly mentioned.
  * Section 4:
      o In the naming of the sub-TLVs for Segment ID, I didn't
        understand the need for these to be specifically named as
        "IPv[46] Prefix Node Segment ID" - is there a specific reason
        that one would restrict these sub-TLVs to being relevant to only
        Node SIDs compared to generic IGP Prefix SIDs (which is what is
        implied, to me)? I don't think there is any such restriction.
          + I think there may have been some change in terminology here
            in the SR architecture since the original document was
            written - the aforementioned draft clarified some wording
            somewhere along the way such that a Node-SID is just a
            special name for a particular IGP-Prefix-SID that uniquely
            identifies an LSR.
  * Section 6:
      o 6.1: The text here handles cases where an LSR might remove
        labels from the stack (which is based on both Adj-SID and
        Node-SID), but does not handle the case where actually labels
        might be added to the stack. In the case that we have a binding
        segment being advertised
        (https://tools.ietf.org/html/draft-ietf-spring-segment-routing-04#section-3.6),
        then in fact a single SID might be popped and replaced with N
        other labels (corresponding to labels that are assigned by
        OSPF/IS-IS or some other protocol). Does the wording here need
        to be clarified to say that for traceroute the originating LSR
        MAY also add these new FECs to the Target FEC Stack TLV? Doing
        so would allow it to determine the mapping along that subsequent
        bound LSP.
      o 6.2: Again, I think this text needs to refer to all Prefix SIDs 
        not just the Node-SID.
      o What are the plans to expand §6.4? For example, are there
        clarifications required where SR might introduce new forwarding
        decisions that could be erroneous -- one that might come to mind
        here is that the Adj-SID is being advertised in the IGP for a
        link that does not support labelled forwarding.
  * Section 7:
      o Can the authors clarify what is meant by a 'service segment' in
        this context? draft-ietf-spring-segment-routing does not define
        this term. I know there was originally some discussion of use of
        a particular segment to forward through some intermediate
        function - but at this point, I don't think that there is a
        definition of this anywhere in the SPRING documents.
      o I'm unclear on the intention of this section -- the text reads
        that the LSR should not apply the service function to the
        forwarded packet. To this end, is the operational limitation
        that should be noted here that LSP Ping and Traceroute are not
        suitable to validate paths when MPLS SR service segments are
        used? If this is the case, it would be very useful to state this
        up-front such that this limitation is understood by an operator.

Additionally, there are a few gramatical issues - but I assume that 
these will be cleaned up as we progress this document/with the RFC 
editor, so I haven't called them out.

Thanks for your time considering these comments!

Cheers,
r.