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

["Stefano Previdi (sprevidi)" <[e-mail]>]

Stewart,

I applied some of your comments in the new submitted version of the draft. Some other comments below.


> On Feb 2, 2017, at 1:15 PM, Stewart Bryant <[e-mail]> wrote:
> 
> 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.


the first statement is the generic description of SR as an architecture. Then, I will add a statement regarding the incarnation of the SR header in the mpls dataplane (i.e.: a label stack).


> 
>   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.


the above is confusing because it implies the two are merged.

paths can be topological, service-based or both.


>   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.


the text has been already reviewed and commented multiple time and reflects the agreement of the WG. We specify that SR doesn’t need rsvp-te or ldp. 

In the context of SR, we just don’t need them. On other context they certainly have their value.


> 
> 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.


not really. Please have a look at the architecture and illustrations.


> 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.


this would trigger the neverending debate on whether we should start comparing all aspects pros/cons of control planes (SR vs. ldp/rsvp). 

We’re just interested into how SR works: one sid per pe.


> 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.


what exactly you don’t find clear ?

a label value is 20 bits as per mpls architecture so we map a segment identifier into these bits.


>   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.


yes. Added reference to the architecture draft where indexes are introduced and defined.


>   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?


clearly this is in the scope of RSVP.

With SR we assume controller based SR TE networks where resources (used/available) are reported to the management/controller system and programming of paths done accordingly.

Again, it’s out of scope of this draft.


> 
>   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.


we don’t claim the invention of it. We just illustrate the benefit of it.


>   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


yes, added.


> 
>      *  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.


and so ?


>         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.


I think it’s clear but I can add a few words if it helps you: the SRGB can be learned through different means. However, it is obvious that the SRGB the index is applied to MUST be the one belonging to the neighbor intended to receive the packet.



>   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.


I think the text is clear, no ? it’s not SR but rather the MPLS architecture that requires to use label 16 upwards. SR complies to this.


> 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?


igp.


> 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.


please precise what is confusing to you.


> 
> ==================
> 
> 
> 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.


removed “history”.



> ==============
> 
> 
> 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?


LSP-ping is in the oam draft.

> 
> 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?


please read the arch draft and its security section.

thanks.
s.


> 
> 
>