SR Path Ingress Protection
draft-chen-idr-sr-ingress-protection-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Huaimo Chen , Mehmet Toy , Aijun Wang , Zhenqiang Li , Lei Liu , Xufeng Liu | ||
| Last updated | 2019-07-06 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-chen-idr-sr-ingress-protection-00
Network Working Group H. Chen
Internet-Draft Futurewei
Intended status: Standards Track M. Toy
Expires: January 7, 2020 Verizon
A. Wang
China Telecom
Z. Li
China Mobile
L. Liu
Fujitsu
X. Liu
Volta Networks
July 6, 2019
SR Path Ingress Protection
draft-chen-idr-sr-ingress-protection-00
Abstract
This document describes protocol extensions and procedures for
protecting the ingress node of a Segment Routing (SR) path.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2020.
Chen, et al. Expires January 7, 2020 [Page 1]
Internet-Draft SR Ingress Protection July 2019
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SR Path Ingress Protection Example . . . . . . . . . . . . . 3
4. Behavior after Ingress Failure . . . . . . . . . . . . . . . 4
5. Extensions to BGP . . . . . . . . . . . . . . . . . . . . . . 5
5.1. SR Path Ingress Protection Sub-TLV . . . . . . . . . . . 5
5.1.1. Primary Ingress Sub-TLV . . . . . . . . . . . . . . . 6
5.1.2. Service Sub-TLV . . . . . . . . . . . . . . . . . . . 7
6. Backup Ingress Behavior . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9.1. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . 10
9.2. Ingress Protection Information Sub-TLVs . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Fast protection of a transit node of a Segment Routing (SR) path or
tunnel is described in [I-D.bashandy-rtgwg-segment-routing-ti-lfa]
and [I-D.hu-spring-segment-routing-proxy-forwarding]. However, these
documents do not discuss the procedures for fast protection of the
ingress node of an SR path or tunnel.
This document fills that void and specifies protocol extensions and
procedures for fast protection of the ingress node of an SR path. SR
path and SR tunnel, Ingress node and ingress as well as fast
protection and protection will be used exchangeably.
Chen, et al. Expires January 7, 2020 [Page 2]
Internet-Draft SR Ingress Protection July 2019
2. Terminologies
The following terminologies are used in this document.
SR: Segment Routing
SRv6: SR for IPv6
SRH: Segment Routing Header
SID: Segment Identifier
CE: Customer Edge
PE: Provider Edge
LFA: Loop-Free Alternate
TI-LFA: Topology Independent LFA
TE: Traffic Engineering
BFD: Bidirectional Forwarding Detection
VPN: Virtual Private Network
L3VPN: Layer 3 VPN
FIB: Forwarding Information Base
PLR: Point of Local Repair
BGP: Border Gateway Protocol
IGP: Interior Gateway Protocol
OSPF: Open Shortest Path First
IS-IS: Intermediate System to Intermediate System
3. SR Path Ingress Protection Example
To protect against the failure of the (primary) ingress node of a
(primary) SR path, a backup ingress node is configured or selected
and is different from the (primary) ingress node. A backup SR path
from the backup ingress node is computed and installed. Primary
ingress and ingress as well as primary SR path and SR path will be
used exchangeably.
Chen, et al. Expires January 7, 2020 [Page 3]
Internet-Draft SR Ingress Protection July 2019
Figure 1 shows an example of protecting ingress PE1 of a SR path,
which is from ingress PE1 to egress PE3.
******* *******
[PE1]-----[P1]-----[PE3]
/ | |&&&&&&&& | \ PE1 Ingress
/ | |& | \ CEx Customer Edge
[CE1] | |& | [CE2] Px Non-Ingress
\ | |& | / *** SR Path
\ | &&&&&&&|& | / &&& Backup SR Path
[PE2]-----[P2]-----[PE4]
Figure 1: Protecting Ingress PE1 of SR Path PE1-P1-PE3
In normal operations, CE1 sends the traffic with destination PE3 to
ingress PE1, which imports the traffic into the SR path.
When CE1 detects the failure of ingress PE1, it switches the traffic
to backup ingress PE2, which imports the traffic from CE1 into a
backup SR path. The backup path is from the backup ingress PE2 to
the egress PE3. When the traffic is imported into the backup path,
it is sent to the egress PE3 along the path.
4. Behavior after Ingress Failure
After the failure of the ingress of an SR path happens, there are a
couple of different ways to detect the failure. In each way, there
may be some specific behavior for the traffic source (e.g., CE1) and
the backup ingress (e.g., PE2).
In one way, the traffic source (e.g., CE1) is responsible for fast
detecting the failure of the ingress (e.g., PE1) of an SR path. Fast
detecting the failure means detecting the failure in a few or tens of
milliseconds. The backup ingress (e.g., PE2) is ready to import the
traffic from the traffic source into the backup SR path installed.
In normal operations, the source sends the traffic to the ingress of
the SR path. When the source detects the failure of the ingress, it
switches the traffic to the backup ingress, which delivers the
traffic to the egress of the SR path via the backup SR path.
In another way, the backup ingress is responsible for fast detecting
the failure of the ingress of an SR path.
In normal operations, the source (e.g., CE1) sends the traffic to the
ingress (e.g., PE1) and may send the traffic to the backup ingress
(e.g., PE2). It sends the traffic to the backup ingress (e.g., PE2)
after the ingress fails.
Chen, et al. Expires January 7, 2020 [Page 4]
Internet-Draft SR Ingress Protection July 2019
The backup ingress does not import any traffic from the source into
the backup SR path in normal operations. When it detects the failure
of the ingress, it imports the traffic from the source into the
backup SR path.
5. Extensions to BGP
For a SR path from a primary ingress node to an egress node, a backup
ingress node is selected to protect the failure of the primary
ingress node of the SR path. This section describes the extensions
to BGP for representing the information for protecting the primary
ingress node in a BGP UPDATE message and distributing the information
to the backup ingress node. The information includes a SR backup
path.
[I-D.ietf-idr-segment-routing-te-policy] specifies a way of
representing a SR path in a BGP UPDATE message and distributing the
SR path to the ingress node of the SR path.
This is extended to represent the information for protecting the
primary ingress by defining a few of new Sub-TLVs.
5.1. SR Path Ingress Protection Sub-TLV
A new Sub-TLV, called SR Path Ingress Protection Sub-TLV, is defined.
When a UPDATE message is sent to the backup ingress node for
protecting the primary ingress node of a SR path, the message
contains this Sub-TLV. Its format is illustrated below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD1) | Length (variable) | Flags |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ Sub-TLVs (optional) ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SR Path Ingress Protection Sub-TLV
Type: TBD1 is to be assigned by IANA.
Length: Variable.
Flags: 1 octet. One flag is defined.
Flag A: 1 bit. It is set to
Chen, et al. Expires January 7, 2020 [Page 5]
Internet-Draft SR Ingress Protection July 2019
1: request a backup ingress to let the forwarding entry for the
backup SR path be Active.
0: request a backup ingress to let the forwarding entry for the
backup SR path be inactive initially and to make the entry
be active after detecting the failure of the primary ingress
node of the primary SR path.
A couple types of optional Sub-TLVs are defined, which are Primary
Ingress Sub-TLV and Service Sub-TLV.
5.1.1. Primary Ingress Sub-TLV
A Primary Ingress Sub-TLV indicates the IP address of the primary
ingress node of a primary SR path. It has two formats: one for
primary ingress node IPv4 address and the other for primary ingress
node IPv6 address, which are illustrated below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Ingress IPv4 Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Primary Ingress IPv4 Address Sub-TLV
Type: Its value (1 suggested) is to be assigned by IANA.
Length: 4.
Primary Ingress IPv4 Address: 4 octets. It represents an IPv4 host
address of the primary ingress node of a primary SR path.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (2) | Length (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Ingress IPv6 Address (16 octets) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Primary Ingress IPv6 Address Sub-TLV
Type: Its value (2 suggested) is to be assigned by IANA.
Chen, et al. Expires January 7, 2020 [Page 6]
Internet-Draft SR Ingress Protection July 2019
Length: 16.
Primary Ingress IPv6 Address: 16 octets. It represents an IPv6 host
address of the primary ingress node of a primary SR path.
5.1.2. Service Sub-TLV
A Service Sub-TLV contains a service ID or label to be added into a
packet to be carried by a SR path. It has three formats: the first
one for the service identified by a label, the second one for the
service identified by a service identifier (ID) of 32 bits, and the
third one for the service identified by a service identifier (ID) of
128 bits. Their formats are illustrated below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (3) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Service Label (20 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Service Label Sub-TLV
Type: Its value (3 suggested) is to be assigned by IANA.
Length: 4.
Service Label: the least significant 20 bits. It represents a label
of 20 bits.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (4) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: 32 Bits Service ID Sub-TLV
Type: Its value (4 suggested) is to be assigned by IANA.
Length: 4.
Service ID: 4 octets. It represents a Service Identifier (ID) of 32
bits.
Chen, et al. Expires January 7, 2020 [Page 7]
Internet-Draft SR Ingress Protection July 2019
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (5) | Length (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service ID (16 octets) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: 128 Bits Service ID Sub-TLV
Type: Its value (5 suggested) is to be assigned by IANA.
Length: 16.
Service ID: 16 octets. It represents a Service Identifier (ID) of
128 bits.
6. Backup Ingress Behavior
When a backup ingress node receives a UPDATE message containing the
information for protecting the primary ingress node of a SR path, it
installs a forwarding entry in its FIB based on the information. The
information is encoded in a SR policy of the following structure:
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
Attributes:
Tunnel Encaps Attribute (23)
Tunnel Type (15): SR Policy
SR Path Ingress Protection Sub-TLV
Primary Ingress Sub-TLV
Service Sub-TLV
Preference Sub-TLV
Binding SID Sub-TLV
Explicit NULL Label Policy (ENLP) Sub-TLV
Priority Sub-TLV
Policy Name Sub-TLV
Segment List Sub-TLV
Weight Sub-TLV
Segment Sub-TLV
Segment Sub-TLV
...
...
Where:
o SR Policy SAFI NLRI is defined in
[I-D.ietf-idr-segment-routing-te-policy].
Chen, et al. Expires January 7, 2020 [Page 8]
Internet-Draft SR Ingress Protection July 2019
o Tunnel Encapsulation Attribute is defined in
[I-D.ietf-idr-tunnel-encaps].
o Tunnel Type of SR Policy is defined in
[I-D.ietf-idr-segment-routing-te-policy].
o SR Path Ingress Protection, Primary Ingress and Service Sub-TLVs
are defined in this document.
o Preference, Binding SID, ENLP, Priority, Policy Name, Segment
List, Weight and Segment Sub-TLVs are defined in
[I-D.ietf-idr-segment-routing-te-policy].
After receiving a SR policy with a SR Path Ingress Protection Sub-
TLV, the backup ingress node will install one or more candidate paths
into its "BGP table". Another module such as SRPM will choose one or
more paths and install the forwarding entries for them in the data
plane.
The forwarding entries for the paths installed in the data plane will
be set to be inactive if the flag A in the SR Path Ingress Protection
Sub-TLV is zero. When the primary ingress node fails, these
forwarding entries are set to be active. The failure of the primary
ingress may be detected by the backup ingress node through using a
mechanism such as BFD. The IP address of the primary ingress in the
Primary Ingress Sub-TLV may be used for detecting the failure of the
primary ingress node.
If the flag A in the SR Path Ingress Protection Sub-TLV is one, then
the forwarding entries for the paths installed in the data plane will
be set to be active.
When there is a Service Sub-TLV in the SR Path Ingress Protection
Sub-TLV, the ID or Label in the Service Sub-TLV will be included in
the forwarding entries. When a packet is imported into a backup SR
path using the forwarding entries, the service ID or Label is pushed
first and then the sequence of segments represented in the Segment
List Sub-TLV.
7. Security Considerations
Protocol extensions defined in this document do not affect the BGP
security other than those as discussed in the Security Considerations
section of [RFC5575].
Chen, et al. Expires January 7, 2020 [Page 9]
Internet-Draft SR Ingress Protection July 2019
8. Acknowledgements
TBD
9. IANA Considerations
9.1. BGP Tunnel Encapsulation Attribute Sub-TLVs
Under Existing Registry Name: "BGP Tunnel Encapsulation Attribute
Sub-TLVs", IANA is requested to assign a new Sub-TLV value for SR
Path Ingress Protection as follows:
Value sub-TLV Name Reference
----- ------------------------------------ --------------
TBD1 SR Path Ingress Protection Sub-TLV This Document
9.2. Ingress Protection Information Sub-TLVs
A new registry called "Ingress Protection Information Sub-TLVs" is
defined in this document. IANA is requested to create and maintain
new registry:
o Ingress Protection Information Sub-TLVs
Initial values for the registry are given below. The future
assignments are to be made through IETF Review [RFC5226].
Value sub-TLV Name Reference
----- ------------------------------------- --------------
0 Reserved
1 Primary Ingress IPv4 Address Sub-TLV This Document
2 Primary Ingress IPv6 Address Sub-TLV This Document
3 Service Label Sub-TLV This Document
4 32 Bits Service ID Sub-TLV This Document
5 128 Bits Service ID Sub-TLV This Document
6-255 Unassigned
10. References
10.1. Normative References
[I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Mattes, P., Rosen, E., Jain,
D., and S. Lin, "Advertising Segment Routing Policies in
BGP", draft-ietf-idr-segment-routing-te-policy-07 (work in
progress), July 2019.
Chen, et al. Expires January 7, 2020 [Page 10]
Internet-Draft SR Ingress Protection July 2019
[I-D.ietf-idr-tunnel-encaps]
Patel, K., Velde, G., Ramachandra, S., and E. Rosen, "The
BGP Tunnel Encapsulation Attribute", draft-ietf-idr-
tunnel-encaps-12 (work in progress), May 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
Scope Link State PDUs (LSPs)", RFC 7356,
DOI 10.17487/RFC7356, September 2014,
<https://www.rfc-editor.org/info/rfc7356>.
10.2. Informative References
[I-D.bashandy-rtgwg-segment-routing-ti-lfa]
Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S.,
Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P.
Camarillo, "Topology Independent Fast Reroute using
Segment Routing", draft-bashandy-rtgwg-segment-routing-ti-
lfa-05 (work in progress), October 2018.
[I-D.hegde-spring-node-protection-for-sr-te-paths]
Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu,
"Node Protection for SR-TE Paths", draft-hegde-spring-
node-protection-for-sr-te-paths-05 (work in progress),
July 2019.
[I-D.hu-spring-segment-routing-proxy-forwarding]
Hu, Z., Chen, H., Yao, J., Bowers, C., and Y. Zhu, "SR-TE
Path Midpoint Protection", draft-hu-spring-segment-
routing-proxy-forwarding-03 (work in progress), April
2019.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
bogdanov@google.com, b., and P. Mattes, "Segment Routing
Policy Architecture", draft-ietf-spring-segment-routing-
policy-03 (work in progress), May 2019.
[I-D.sivabalan-pce-binding-label-sid]
Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J.,
Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID
in PCE-based Networks.", draft-sivabalan-pce-binding-
label-sid-06 (work in progress), February 2019.
Chen, et al. Expires January 7, 2020 [Page 11]
Internet-Draft SR Ingress Protection July 2019
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<https://www.rfc-editor.org/info/rfc5575>.
Authors' Addresses
Huaimo Chen
Futurewei
Boston, MA
USA
Email: huaimo.chen@futurewei.com
Mehmet Toy
Verizon
USA
Email: mehmet.toy@verizon.com
Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing 102209
China
Email: wangaj.bri@chinatelecom.cn
Zhenqiang Li
China Mobile
32 Xuanwumen West Ave, Xicheng District
Beijing 100053
China
Email: lizhengqiang@chinamobile.com
Chen, et al. Expires January 7, 2020 [Page 12]
Internet-Draft SR Ingress Protection July 2019
Lei Liu
Fujitsu
USA
Email: liulei.kddi@gmail.com
Xufeng Liu
Volta Networks
McLean, VA
USA
Email: xufeng.liu.ietf@gmail.com
Chen, et al. Expires January 7, 2020 [Page 13]