Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06

[Stewart Bryant <[e-mail]>]

Here are a number of WGLC comments on this document.

- Stewart

                   Segment Routing with MPLS data plane
                draft-ietf-spring-segment-routing-mpls-06

Abstract

    Segment Routing (SR) leverages the source routing paradigm.  A node
    steers a packet through a controlled set of instructions, called
    segments, by prepending the packet with an SR header.

SB> This is SR MPLS. The above text implies a special header. Surely
SB> it appends a stack of MPLS label stack entries that encode the instructions
SB> as label values.

    A segment can
    represent any instruction, topological or service-based.
SB> and more!
    SR allows
    to enforce a flow through any topological path and service chain
    while maintaining per-flow state only at the ingress node to the SR
    domain.

SB> The above does not read well.
SB> Surely something like:
SB> SR allows an ingress node to steer a packet through a
SB> topological path specifying which service actions or other
SB> operations need to executed on arrival as a each specified node.

    Segment Routing can be directly applied to the MPLS architecture with
    no change in the forwarding plane.  This drafts describes how Segment
    Routing operates on top of the MPLS data plane.

===========================


2.  Illustration

    Segment Routing, applied to the MPLS data plane, offers the ability
    to tunnel services (VPN, VPLS, VPWS) from an ingress PE to an egress
    PE, without any other protocol than ISIS or OSPF
    ([I-D.ietf-isis-segment-routing-extensions] and
    [I-D.ietf-ospf-segment-routing-extensions]).  LDP and RSVP-TE
    signaling protocols are not required.

SB> Strictly no protocol is required as we did in MPLS-TP.
SB> What you are saying is that by embedding additional
SB> information in the the link state igp in use, you remove the
SB> dependence on LDP, and RSVP-TE, although of course RSVP-TE
SB> does run-time bandwidth accounting which you have to move to
SB> a central place.

SB> I suspect that the reader would be better served by putting the
SB> rest of this after explaining how the protocol mapping works.

==================


    Supporting MPLS services (VPN, VPLS, VPWS) with SR has the following
    benefits:

       Simple operation: one single intra-domain protocol to operate: the
       IGP.  No need to support IGP synchronization extensions as
       described in [RFC5443] and [RFC6138].

       Excellent scaling: one Node-SID per PE.

SB> Is this all it seems. If you are going to steer the packet
SB> I think you need more than one node-SID to get the packet there.
SB> I presume the point is (and it should be brought out) that with
SB> liberal label retention you have a label per adjacency that maps
SB> to the remote PE (in the RP), although only one is in the FIB. If you have
SB> an RSVP-TE path you have more than one label per PE, you have
SB> one per constructed path, but in the FIB you only need to specify
SB> a single label imposition, whilst in SR, you need to specify a
SB> multi-label imposition.

SB> As I understand it different vendors have different approaches
SB> to label aggregation which may further complicate the issue, but
SB> this text needs to be neutral on that point.


  3.  MPLS Instantiation of Segment Routing

    MPLS instantiation of Segment Routing fits in the MPLS architecture
    as defined in [RFC3031] both from a control plane and forwarding
    plane perspective:

    o  From a control plane perspective [RFC3031] does not mandate a
       single signaling protocol.  Segment Routing proposes to use the
       Link State IGP as its use of information flooding fits very well
       with label stacking on ingress.

SB> Surely you propose to be protocol agnostic? For example SR will work just as
SB> well with for example a pub-sub approach.

    o  From a forwarding plane perspective, Segment Routing does not
       require any change to the forwarding plane.

    When applied to MPLS, a Segment is a LSP and the 20 right-most bits
    of the segment are encoded as a label. This implies that, in the
    MPLS instantiation, the SID values are allocated within a reduced
    20-bit space out of the 32-bit SID space.

SB> That is a very strange way of saying that in MPLS SIDs are 20
SB> bits, although of course they are often less than 20 bits
SB> as other MPLS applications need to use the same label table.
SB> If SIDs were 32 bits, then you would need to encode them across
SB> multiple labels, which I have not seen proposed.

    The notion of indexed global segment fits the MPLS architecture
    [RFC3031] as the absolute value allocated to any segment (global or
    local) can be managed by a local allocation process (similarly to
    other MPLS signaling protocols).

SB> You need some text to introduce the above rather than pull it out
SB> of a hat.


    If present, SR can coexist and interworks with LDP and RSVP
    [I-D.ietf-spring-segment-routing-ldp-interop].

    The source routing model described in
    [I-D.ietf-spring-segment-routing] is inherited from the ones proposed
    by [RFC1940] and [RFC2460].  The source routing model offers the
    support for explicit routing capability.

SB> SR goes back prior to RFC791, which also included source routing.


    Contrary to RSVP-based explicit routes where tunnel midpoints
    maintain states, SR-based explicit routes only require per-flow
    states at the ingress edge router where the traffic engineer policy
    is applied.

SB> What about bandwidth management?

    Contrary to RSVP-based explicit routes which consist in non-ECMP
    circuits (similar to ATM/FR), SR-based explicit routes can be built
    as list of ECMP-aware node segments and hence ECMP-aware traffic
    engineering is natively supported by SR.

SB> You mean loose source routing, which is again an old concept.

    When Segment Routing is instantiated over the MPLS data plane the
    following applies:

    o  A list of segments is represented as a stack of labels.

SB> The items in the stack are technically LSEs.

    o  The active segment is the top label.

    o  The CONTINUE operation is implemented as an MPLS swap operation.
       The outgoing label value is computed as follows:

SB> CONTINUE need a reference

       *  When the same Segment Routing Global Block (SRGB, defined in
          [I-D.ietf-spring-segment-routing] is used throughout the SR
          domain, the outgoing label value is equal to the incoming label
          value.

       *  When different SRGBs are used, the outgoing label value is set
          as: [SRGB(next_hop)+index].

SB> This is a continue, so isn't it label = label + SRGB_base_next - SRGB_base_this?
SB> The order can be the other way around by this never gives negative numbers.


          If the index can't be applied to
          the SRGB (i.e.: if the index points outside the SRGB of the
          next-hop or the next-hop has not advertised a valid SRGB), then
          no outgoing label value can be computed and the next-hop MUST
          be considered as not supporting the MPLS operations for that
          particular SID.

SB> Presumably you also need to take a management action since the
SB> control plane should no allow the situation to occur.

       *  The index and the SRGB may be learned through different means.
          Obviously, the SRGB MUST be the one the index is related to.

SB> The above is a little opaque.


    o  The NEXT operation is implemented as an MPLS pop operation.  The
       NEXT operation does not require any mapping to an outgoing label
       hence the SRGB is irrelevant for this operation.

SB> NEXT needs a reference

    o  The PUSH operation is implemented as an MPLS push of a label
       stack.

SB> POP needs a reference, and don't you actually push one or more LSE?

    o  The Segment Routing Global Block (SRGB) values MUST be greater
       than 15 in order to preserve values 0-15 as defined in [RFC3032].

SB> What you are saying is that the SRGB base value must have a number
SB> greater than the top of the special purpose label space (0..15), although
SB> as it was expressed it looked like you wanted to have room for them
SB> in the SR label space.

SB> Indeed I think the document set conflates SGRB with SRGB_base and
SB> ought to define both terms.

SB> I think it might be worth noting that the obvious implementation of
SB> RFC7474 would be to move the ceiling of the SPLs rather than
SB> creating a new table in h/w and thus it would be sensible leave
SB> some space between 15 and SRGB-base.

======================


4.1.  Example 1
...

    In conclusion, the path followed by P1 is R1-R2--R3-R8.  The ECMP-
    awareness ensures that the traffic be load-shared between any ECMP
    path, in this case the two north and south links between R2 and R3.



SB> Ah now how is that ECMP being calculated? If it is based on the
SB> labels in a stack without an EL, isn't there a tendency to reduce
SB> the entropy given the guideline to allocate the same SRGB everywhere?

=====================

5.1.  LDP LSP segment combined with IGP segments

    The example illustrates a segment-routing policy including IGP
    segments and LDP LSP segments.

                       SL1---S2---SL3---L4---SL5---S6
                                   |               |
                                   +---------------+

            Figure 4: LDP LSP segment combined with IGP segments

SB> This and the text that follows is very confusing. It would be helpful to define your
SB> SL, S, L notation up front.

==================


5.2.  RSVP-TE LSP segment combined with IGP segments

    The example illustrates a segment-routing policy including IGP
    segments and RSVP-TE LSP segments.

                        S1---S2---RS3---R4---RS5---S6
                                   |               |
                                   +---------------+

          Figure 5: RSVP-TE LSP segment combined with IGP segments

SB> Again starting with the notation would be helpful to the reader.

=============



    In the MPLS instantiation, as the packet travels through the SR
    domain, the stack is depleted and the segment list history is
    gradually lost.

SB> Strictly the history is not gradually lost, it is never there.
SB> When you see a label stack, you know the future of the packet
SB> but never the past.


==============


8.  Manageability Considerations

    This document describes the applicability of Segment Routing over the
    MPLS data plane.  Segment Routing does not introduce any change in
    the MPLS data plane.  Manageability considerations described in
    [I-D.ietf-spring-segment-routing] applies to the MPLS data plane when
    used with Segment Routing.

SB> Maybe I missed it, but I could not see any discussion on the implications
SB> for LSP-ping. Does that just work out of the box or does it need changes?

  9.  Security Considerations

    This document does not introduce additional security requirements and
    mechanisms other than the ones described in
    [I-D.ietf-spring-segment-routing].

SB> I think that the MPLS element of the security considerations might be
SB> better placed here with the rest of the MPLS text.
SB> By minimising the range of the labels used, isn't path guessing more
SB> of a concern, and isn't there a greater chance that a misforwarded packet
SB> will get to a destination rather than be dropped?
SB>
SB> Doesn't SR make it a tad easier for the pervasive monitoring people
SB> to figure out where a packet is going than in an LSP or RSVP-TE controlled
SB> network?