draft-ietf-spring-mpls-anycast-segments-01.txt   draft-ietf-spring-mpls-anycast-segments-02.txt 
SPRING Working Group P. Sarkar, Ed. SPRING Working Group P. Sarkar, Ed.
Internet-Draft Arrcus, Inc. Internet-Draft Arrcus, Inc.
Intended status: Standards Track H. Gredler Intended status: Standards Track H. Gredler
Expires: October 13, 2017 RtBrick Inc. Expires: August 2, 2018 RtBrick Inc.
C. Filsfils C. Filsfils
S. Previdi
Cisco Systems, Inc. Cisco Systems, Inc.
S. Previdi
Individual
B. Decraene B. Decraene
Orange Orange
M. Horneffer M. Horneffer
Deutsche Telekom Deutsche Telekom
April 11, 2017 January 29, 2018
Anycast Segments in MPLS based Segment Routing Anycast Segments in MPLS based Segment Routing
draft-ietf-spring-mpls-anycast-segments-01 draft-ietf-spring-mpls-anycast-segments-02
Abstract Abstract
Instead of forwarding to a specific device or to all devices in a Instead of forwarding to a specific device or to all devices in a
group, anycast addresses, let network devices forward a packet to (or group, anycast addresses, let network devices forward a packet to (or
steer it through) one or more topologically nearest devices in a steer it through) one or more topologically nearest devices in a
specific group of network devices. The use of anycast addresses has specific group of network devices. The use of anycast addresses has
been extended to the Segment Routing (SR) network, wherein a group of been extended to the Segment Routing (SR) network, wherein a group of
SR-capable devices can represent a anycast address, by having the SR-capable devices can represent a anycast address, by having the
same Segment Routing Global Block (SRGB) provisioned on all the same Segment Routing Global Block (SRGB) provisioned on all the
skipping to change at page 2, line 5 skipping to change at page 2, line 8
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 13, 2017. This Internet-Draft will expire on August 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 3, line 30 skipping to change at page 3, line 32
corresponding anycast address in its IGP link-state advertisements corresponding anycast address in its IGP link-state advertisements
along with the SID provisioned. Source devices on receiving such along with the SID provisioned. Source devices on receiving such
anycast prefix segment advertisements, finds out the topologically anycast prefix segment advertisements, finds out the topologically
nearest device that originated the anycast segment and forwards nearest device that originated the anycast segment and forwards
packets destined to the same on the shortest-path to the nearest packets destined to the same on the shortest-path to the nearest
device. device.
[I-D.ietf-spring-segment-routing] requires all devices in a given [I-D.ietf-spring-segment-routing] requires all devices in a given
anycast group to implement the exact same SRGB block(s). This anycast group to implement the exact same SRGB block(s). This
requirement will always be met in SR network deployed over IPV6 requirement will always be met in SR network deployed over IPV6
forwarding plane [I-D.previdi-6man-segment-routing-header]. For SR forwarding plane [I-D.ietf-6man-segment-routing-header]. For SR over
over MPLS dataplane [I-D.ietf-spring-segment-routing-mpls], while MPLS dataplane [I-D.ietf-spring-segment-routing-mpls], while this is
this is a simple (and hence more desirable) solution, the same may a simple (and hence more desirable) solution, the same may not be
not be possible in a multi-vendor networks deploying devices with possible in a multi-vendor networks deploying devices with varying
varying hardware capabilities. hardware capabilities.
In MPLS-based SR deployments, the segments on a given source router In MPLS-based SR deployments, the segments on a given source router
are actually mapped to a MPLS labels allocated from the local label are actually mapped to a MPLS labels allocated from the local label
pool carved out by the device for accomodating the SRGB. In multi- pool carved out by the device for accomodating the SRGB. In multi-
vendor deployments with various types of devices deployed in the same vendor deployments with various types of devices deployed in the same
network topology, such a anycast group may contain a good combination network topology, such a anycast group may contain a good combination
of devices from different vendors and have different internal of devices from different vendors and have different internal
hardware capabilities. In such environments it is not sufficient to hardware capabilities. In such environments it is not sufficient to
assume that all the devices in a anycast group will be able to assume that all the devices in a anycast group will be able to
allocate exactly the same range of labels for implementing the SRGB. allocate exactly the same range of labels for implementing the SRGB.
skipping to change at page 8, line 18 skipping to change at page 8, line 18
For each anycast prefix segment, this document also defines a 'Common For each anycast prefix segment, this document also defines a 'Common
Anycast Prefix Segment Label' (hereafter referred to CAPSL). The Anycast Prefix Segment Label' (hereafter referred to CAPSL). The
value of this label is derived by applying the SID index associated value of this label is derived by applying the SID index associated
with the prefix segment as an offset to the CA-SRGB configured on the with the prefix segment as an offset to the CA-SRGB configured on the
specific device. Since the operator MUST configure the same CA-SRGB specific device. Since the operator MUST configure the same CA-SRGB
values on all devices in the IGP domain, all devices shall associate values on all devices in the IGP domain, all devices shall associate
the same CAPSL label value for a given anycast prefix segment. the same CAPSL label value for a given anycast prefix segment.
Table 1 below shows the CAPSL labels allocated by any device for the Table 1 below shows the CAPSL labels allocated by any device for the
various prefix segments found in Figure 2, with CA-SRGB set to various prefix segments found in Figure 2, with CA-SRGB set to
3000-4000 on all devices. 2000-3000 on all devices.
+-----+---------------+-------------+ +-----+---------------+-------------+
| SID | CA-SRGB Range | CAPSL Value | | SID | CA-SRGB Range | CAPSL Value |
+-----+---------------+-------------+ +-----+---------------+-------------+
| 10 | 2000-3000 | 2010 | | 10 | 2000-3000 | 2010 |
| 20 | 2000-3000 | 2020 | | 20 | 2000-3000 | 2020 |
| 30 | 2000-3000 | 2030 | | 30 | 2000-3000 | 2030 |
| 40 | 2000-3000 | 2040 | | 40 | 2000-3000 | 2040 |
| 100 | 2000-3000 | 2100 | | 100 | 2000-3000 | 2100 |
+-----+---------------+-------------+ +-----+---------------+-------------+
skipping to change at page 10, line 45 skipping to change at page 10, line 45
When a MPLS packet on the wire first hits a device, the forwarding When a MPLS packet on the wire first hits a device, the forwarding
hardware reads the topmost label in the MPSL header and looks up the hardware reads the topmost label in the MPSL header and looks up the
default label lookup table associated with the interface on which the default label lookup table associated with the interface on which the
label has been received. This table is generally called LFIB. The label has been received. This table is generally called LFIB. The
range of labels found in the LFIB constitutes the default label range of labels found in the LFIB constitutes the default label
space. space.
This document introduces a separate virtual label lookup table This document introduces a separate virtual label lookup table
(hereafter referred to as Virtual LFIB or V-LFIB), that represents a (hereafter referred to as Virtual LFIB or V-LFIB), that represents a
label space which is also separate from the actual label space label space which is also separate from the actual label space
represented by the default LFIB. The label value may be present in represented by the default LFIB. The Virtual LFIB is much like a
both the default and Virtual LFIB. However the forwarding semantics decicated context-specific label space as defined in RFC 5331
associated with the label under the default and Virtual LFIB may not [RFC5331]. A label value may be present in both the default and
be same. Following are the fields of a typical entry of this table. Virtual LFIB. However the forwarding semantics associated with the
label under the default and Virtual LFIB may not be same. Following
are the fields of a typical entry of this table.
o CAPSL-Label: The CAPSL label value derived from the SID index o CAPSL-Label: The CAPSL label value derived from the SID index
associated with a given prefix segment originated by another associated with a given prefix segment originated by another
device in the same network. Refer to Section 3.1.2 for more device in the same network. Refer to Section 3.1.2 for more
details. This is also the key field for this table. details. This is also the key field for this table.
o Forwarding Semantics: This is once again one or more tuples of o Forwarding Semantics: This is once again one or more tuples of
following items. following items.
* Outgoing-Label: The label(s) allocated by the neighbor * Outgoing-Label: The label(s) allocated by the neighbor
skipping to change at page 11, line 42 skipping to change at page 11, line 45
In cases where a prefix segment is reachable via multiple shortest In cases where a prefix segment is reachable via multiple shortest
paths on a given device, the corresponding entry for the prefix SID paths on a given device, the corresponding entry for the prefix SID
MUST have as many forwarding entries in the Virtual LFIB table as the MUST have as many forwarding entries in the Virtual LFIB table as the
number of shortest-paths found for the corresponding prefix on the number of shortest-paths found for the corresponding prefix on the
device. device.
Figure 3 below shows how the Virtual LFIB table on each of devices in Figure 3 below shows how the Virtual LFIB table on each of devices in
group A should look like. Please note that some of the prefix group A should look like. Please note that some of the prefix
segments has multiple forwarding semantics associated with them. For segments has multiple forwarding semantics associated with them. For
example, on device A1, the prefix SID 10 (originated by PE3) is example, on device A1, the prefix SID 30 (originated by PE3) is
reachable through its neighbors A3 and A4. And as per the SRGB reachable through its neighbors A3 and A4. And as per the SRGB
advertised by A3 and A4, the labels allocated by A3 and A4 are 3030 advertised by A3 and A4, the labels allocated by A3 and A4 are 3030
and 4030 respectively. Hence A1 has added two forwarding entries for and 4030 respectively. Hence A1 has added two forwarding entries for
the prefix SID 30 in its Virtual LFIB table. the prefix SID 30 in its Virtual LFIB table.
CA-SRGB configured on all devices: {2000-3000} CA-SRGB configured on all devices: {2000-3000}
+========+=============+=======+========================+ +========+=============+=======+========================+
| | | Forwarding Semantics | | | | Forwarding Semantics |
| Device | CAPSL-Label |--------------------------------| | Device | CAPSL-Label |--------------------------------|
| | | Outgoing-Label | Outgoing-Link | | | | Outgoing-Label | Outgoing-Link |
skipping to change at page 14, line 34 skipping to change at page 14, line 34
The proposal above, ensures that a MPLS packet sent to (or taking The proposal above, ensures that a MPLS packet sent to (or taking
transit through) a given anycast group, when reaching at a transit through) a given anycast group, when reaching at a
topologically nearest device in the group where CA-SRGB does not topologically nearest device in the group where CA-SRGB does not
match SRGB provisioned on it, always arrives with the APSL-label that match SRGB provisioned on it, always arrives with the APSL-label that
is derived from the device's SRGB, and the SID associated with the is derived from the device's SRGB, and the SID associated with the
corresponding anycast prefix segment. Note in the above topology, corresponding anycast prefix segment. Note in the above topology,
assuming domain-wide CA-SRGB is set to (2000-3000) on all nodes, assuming domain-wide CA-SRGB is set to (2000-3000) on all nodes,
while nodes A1, A3 and A4 will advertise the SID 100 with P-Flag(No- while nodes A1, A3 and A4 will advertise the SID 100 with P-Flag(No-
PHP) set to 1, node A2 will advertise the same anycast prefix SID PHP) set to 1, node A2 will advertise the same anycast prefix SID
with P-Flag unset. This is because on node A1 the domain-wide CA- with P-Flag unset. This is because the domain-wide CA-SRGB is
SRGB is identical to the local SRGB provisioned on A2. identical to the local SRGB provisioned on A2.
In Figure 2, when PE1 or PE2 intends to steer a packet destined for In Figure 2, when PE1 or PE2 intends to steer a packet destined for
PE3 or PE4, through the anycast group A (SID 100), it needs to PE3 or PE4, through the anycast group A (SID 100), it needs to
forward the packet to R1 (SRGB:7000-8000), after putting the label forward the packet to R1 (SRGB:7000-8000), after putting the label
7100 (derived from R1's SRGB), at top of the label stack in the MPLS 7100 (derived from R1's SRGB), at top of the label stack in the MPLS
header. However when the same packet is forwarded to A1 (one of the header. However when the same packet is forwarded to A1 (one of the
topologicaly nearest devices in group A), R1 shall not POP (or topologicaly nearest devices in group A), R1 shall not POP (or
remove) the label 7100. Instead R1 shall replace it with the label remove) the label 7100. Instead R1 shall replace it with the label
1100 while forwarding to A1. While forwarding to A2, since A2 would 1100 while forwarding to A1. While forwarding to A2, since A2 would
have advertised the anycast SID 100 with P-Flag (No-PHP) unset, R1 have advertised the anycast SID 100 with P-Flag (No-PHP) unset, R1
shall POP the incoming label 7100 before forwarding it to R1. shall POP the incoming label 7100 before forwarding it to A2.
3.2.4. Programming Anycast Prefix Segments 3.2.4. Programming Anycast Prefix Segments
The proposal specified in Section 3.2.3, ensures that a MPLS packet The proposal specified in Section 3.2.3, ensures that a MPLS packet
destined to (or steered via) a anycast prefix segment always arrives destined to (or steered via) a anycast prefix segment always arrives
at the nearest device in the anycast group with a label derived from at the nearest device in the anycast group with a label derived from
the device's SRGB and the SID associated with the corresponding the device's SRGB and the SID associated with the corresponding
anycast prefix segment, as the top-most label label stack in its MPLS anycast prefix segment, as the top-most label label stack in its MPLS
header. If this label is also the bottom-most label (S=1), it means header. If this label is also the bottom-most label (S=1), it means
packet has been destined to the anycast segment, and should be packet has been destined to the anycast segment, and should be
skipping to change at page 17, line 8 skipping to change at page 17, line 8
+----+--+ +----+--+ +----+--+ +----+--+ +----+--+ +----+--+
| | | |
| | | |
+-------------------------+ +-------------------------+
Figure 4: Packet Flow through MPLS-based SR Anycast Segments Figure 4: Packet Flow through MPLS-based SR Anycast Segments
4. Acknowledgements 4. Acknowledgements
Many many thanks to Shraddha Hegde, Eric Rosen, Chris Bowers and Many many thanks to Shraddha Hegde, Eric Rosen, Chris Bowers and
Stephane Litkowski for their valuable inputs. Stephane Litkowski for their valuable inputs. Many thanks to Paresh
Khatri, Alexander Vainshtein and Cheng Li for providing review
comments as well.
5. IANA Considerations 5. IANA Considerations
N/A. - No protocol changes are proposed in this document. N/A. - No protocol changes are proposed in this document.
6. Security Considerations 6. Security Considerations
This document does not introduce any change in any of the protocol This document does not introduce any change in any of the protocol
specifications. specifications.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space",
RFC 5331, DOI 10.17487/RFC5331, August 2008,
<https://www.rfc-editor.org/info/rfc5331>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-6man-segment-routing-header]
Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,
Field, B., daniel.voyer@bell.ca, d.,
daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,
Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,
D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing
Header (SRH)", draft-ietf-6man-segment-routing-header-08
(work in progress), January 2018.
[I-D.ietf-isis-segment-routing-extensions] [I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura,
Extensions for Segment Routing", draft-ietf-isis-segment- "IS-IS Extensions for Segment Routing", draft-ietf-isis-
routing-extensions-04 (work in progress), May 2015. segment-routing-extensions-15 (work in progress), December
2017.
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] [I-D.ietf-ospf-ospfv3-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
Extensions for Segment Routing", draft-ietf-ospf-ospfv3- Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
segment-routing-extensions-02 (work in progress), February segment-routing-extensions-10 (work in progress),
2015. September 2017.
[I-D.ietf-ospf-segment-routing-extensions] [I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment- Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-04 (work in progress), February 2015. routing-extensions-24 (work in progress), December 2017.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
and R. Shakir, "Segment Routing Architecture", draft-ietf- Litkowski, S., and R. Shakir, "Segment Routing
spring-segment-routing-03 (work in progress), May 2015. Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., Litkowski, S., and R. Shakir, "Segment Routing with MPLS
and E. Crabbe, "Segment Routing with MPLS data plane", data plane", draft-ietf-spring-segment-routing-mpls-11
draft-ietf-spring-segment-routing-mpls-01 (work in (work in progress), October 2017.
progress), May 2015.
[I-D.ietf-spring-sr-yang] [I-D.ietf-spring-sr-yang]
Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG
Data Model for Segment Routing", draft-ietf-spring-sr- Data Model for Segment Routing", draft-ietf-spring-sr-
yang-00 (work in progress), July 2015. yang-08 (work in progress), December 2017.
[I-D.previdi-6man-segment-routing-header]
Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6
Segment Routing Header (SRH)", draft-previdi-6man-segment-
routing-header-06 (work in progress), May 2015.
Authors' Addresses Authors' Addresses
Pushpasis Sarkar (editor) Pushpasis Sarkar (editor)
Arrcus, Inc. Arrcus, Inc.
Bangalore, KA 560103 Bangalore, KA 560103
India India
Email: pushpasis.ietf@gmail.com Email: pushpasis.ietf@gmail.com
skipping to change at page 18, line 35 skipping to change at page 19, line 4
Arrcus, Inc. Arrcus, Inc.
Bangalore, KA 560103 Bangalore, KA 560103
India India
Email: pushpasis.ietf@gmail.com Email: pushpasis.ietf@gmail.com
Hannes Gredler Hannes Gredler
RtBrick Inc. RtBrick Inc.
Email: hannes@rtbrick.com Email: hannes@rtbrick.com
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
BE BE
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Stefano Previdi Stefano Previdi
Cisco Systems, Inc. Individual
Via Del Serafico, 200
Rome 00142
Italy Italy
Email: sprevidi@cisco.com Email: stefano@previdi.net
Bruno Decraene Bruno Decraene
Orange Orange
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Martin Horneffer Martin Horneffer
Deutsche Telekom Deutsche Telekom
Hammer Str. 216-226 Hammer Str. 216-226
Muenster 48153 Muenster 48153
DE DE
 End of changes. 27 change blocks. 
49 lines changed or deleted 62 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/