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?
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
