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

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Wed, 01 Feb 2017 07:49:17 -0800

Hi

Also  support as a co-author

Ahmed

On 1/30/2017 12:58 AM, Martin Horneffer wrote:
> Hello,
>
> support from me as co-author and operator.
>
> Bets regards, Martin
>
>
> Am 27.01.17 um 12:05 schrieb Martin Vigoureux:
>>
>> Hello Working Group,
>>
>> This email starts a 2-week Working Group Last Call on 
>> draft-ietf-spring-segment-routing-mpls-06 [1].
>>
>> ¤ Please read the document if you haven't read the most recent
>> version yet, and send your comments to the list, no later than the
>> *12th of February*.
>> Note that this is *not only* a call for comments on the document; it 
>> is also a call for support (or not) to publish this document as a 
>> Proposed Standard RFC.
>>
>> ¤ We have already polled for IPR knowledge on this document and all 
>> Authors have replied.
>> IPR exists against this document and has been disclosed [2].
>>
>> Thank you
>>
>> M&B
>>
>> ---
>> [1] 
>> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
>> [2] 
>> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-mpls
>>
>> _______________________________________________
>> spring mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/spring
>>
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 2 Feb 2017 12:15:56 +0000

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?

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 7 Feb 2017 13:51:25 +0000

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 <[email-masked]> wrote:
> 

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

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

>   Routing operates on top of the MPLS data plane.

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> rest of this after explaining how the protocol mapping works.

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

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

> SB> You need some text to introduce the above rather than pull it out

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

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

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

> SB> CONTINUE need a reference

yes, added.

> SB> The order can be the other way around by this never gives negative numbers.

and so ?

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

> 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> Ah now how is that ECMP being calculated?

igp.

> If it is based on the

please precise what is confusing to you.

removed “history”.

LSP-ping is in the oam draft.

> SB> to figure out where a packet is going than in an LSP or RSVP-TE controlled

please read the arch draft and its security section.

thanks.
s.