Spring Working Group T. Li
Internet-Draft X. Zhou
Intended status: Standards Track CNIC, CAS
Expires: September 24, 2021 Z. Chen
Y. Jia
Huawei Technologies
March 23, 2021
Anycast SID for Flexible and Robust Service in SRv6
draft-li-spring-anycast-sid-service-02
Abstract
Segment Routing enables an operator or an application to specify a
packet processing program. When Segment Routing is applied to IPv6
data plane, the list of IPv6 SIDs in SRH can specify a series of
execution endpoints that hold service functions that process the
packet. However, steering traffic dynamically to the different
execution endpoints requires a specific "re-encapsulating". This
procedure may be complex and take time.
This document proposes A-SID (Anycast-SID) based on SRv6 to achieve
flexible and robust service provision. It uses anycast SID to
identify service functions and locates the service functions based on
anycast routing. The proposed solution can stay compatibility with
the existing SRv6.
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 September 24, 2021.
Li, et al. Expires September 24, 2021 [Page 1]
Internet-DraAnycast SID for Flexible and Robust Service in S March 2021
Copyright Notice
Copyright (c) 2021 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. Anycast SID (A-SID) . . . . . . . . . . . . . . . . . . . . . 3
3. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Usecase1 migration of service function . . . . . . . . . 7
5.2. Usecase2 failover of service function . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Segment Routing [RFC8402] enables an operator or an application to
specify a packet processing program. SRv6 applies Segment Routing to
IPv6 data plane. A new routing header for IPv6, which is called
Segment Routing Header (SRH) [RFC8754] is defined to carry 128-bit
SIDs. The list of IPv6 SIDs in SRH can specify not only a TE path,
but also a series of execution endpoints that hold service functions
that process the packet. In this way, a service function chain
[RFC7665] is formed based on SRv6.
However, more and more functions, such as firewall and DPI, are
deployed in cloud technology and Network Function Virtualization,
which means that a single function may be deployed on multiple
execution locations and the function may be migrated to different
locations frequently. Steering traffic dynamically to the different
Li, et al. Expires September 24, 2021 [Page 2]
Internet-DraAnycast SID for Flexible and Robust Service in S March 2021
execution endpoints requires a specific "re-encapsulating" frequently
at the ingress router. This procedure may be complex and take time.
This document proposes A-SID (Anycast-SID) based on SRv6 to achieve
flexible and robust service provision. In addition to the SIDs that
are used for TE path on the node, specific A-SIDs are used for
service function chain. The execution endpoints share a SID Locator
and the kind of functions is identified by Function and Argument.
The A-SIDs are advertised by the control plane and the packets are
forwarded to the execution endpoints based on anycast routing. The
proposed solution can stay compatibility with the existing SRv6.
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, and BCP 14
[RFC2119]
The definitions of the SRv6 terms, such as SRv6, SID, SRH, locator
and function can be found in [RFC8754], [RFC8402], and [RFC8986].
The definition of Service Function Chain can be found in [RFC7665].
The definition of anycast can be found in [RFC3513].
This document introduces the following new terms:
A-SID: Anycast-based Segment Identifier.
2. Anycast SID (A-SID)
The SRv6 SID contains 16 bytes and can be separated into three parts:
locator, function, and argument. As for the argument, we consider it
as the accessory of function. So this document omits argument for a
clear description and the SRv6 SID can be mainly separated into two
parts: locator and function.
All of the SRv6 endpoints have their own SIDs instantiated in the FIB
table locally and advertised by the control plane as defined in
[RFC8986]. In addition to the existing SRv6 SIDs, the execution
endpoints that hold service functions also have Anycast SIDs. The
Locator of Anycast SID is shared by all the execution endpoints in
the SR domain. In other words, one specific Locator is allocated to
the execution endpoints to identify the Anycast SIDs. The Function
of Anycast SID identifies the kind of service functions that the
endpoint node can provide. That is, if two execution endpoints
provide the same kind of service functions, they will have the same
Anycast SID.
The routing process of A-SID may follow the standard anycast routing.
As another option, the routing of A-SID may be based on the
Li, et al. Expires September 24, 2021 [Page 3]
Internet-DraAnycast SID for Flexible and Robust Service in S March 2021
processing capacity or computing power of endpoint node. The
processing capacity or computing power of endpoint can be advertised
along with the A-SID in the control plane. In this way, two
execution endpoints that provide the same kind of service functions
with the same A-SID can be chosen based on bigger processing capacity
or computing power. The detailed design and extensions to control
plane will be stated in the next version.
0 16 bytes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator | Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|<---Shared locator-->|
|<---------------Anycast SID--------------->|
Figure 1: Anycast SID
For example, the shared Locator is A::/64, Service Functions (SFs)1 -
3 are identified by B1 - B3. Node 1 provides SF1, node 2 and node 3
provide SF2, and node 4 provides SF3. The Anycast SIDs are shown in
Figure 2.
+-+-+ +-+-+ +-+-+
|SF1| |SF2| |SF3|
+-+-+ +-+-+ +-+-+
| | A::B2 |
| +-+-+-+-+ |
| +-+-+-+-+node 2 +-+-+-+-+ |
+-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+
|ingress| +-+-+-+-+ +-+-+-+-+ |egress |
| node +-+-+-+node 1 | |node 4 +-+-+-+ node |
| | +-+-+-+-+ +-+-+-+-+ | |
+-+-+-+-+ A::B1 | +-+-+-+-+ | A::B3 +-+-+-+-+
+-+-+-+-+node 3 +-+-+-+-+
+-+-+-+-+
| A::B2
+-+-+
|SF2|
+-+-+
Figure 2: the Anycast SIDs
A::/64 is allocated and shared by node 1 to node 4.
Li, et al. Expires September 24, 2021 [Page 4]
Internet-DraAnycast SID for Flexible and Robust Service in S March 2021
3. Control Plane
The reachability of Anycast SIDs are advertised by control plane. As
described in [I-D.draft-ietf-lsr-isis-srv6-extensions], a new flag in
"Bit Values for Prefix Attribute Flags Sub-TLV" registry [RFC7794] is
defined to advertise the anycast property. SRv6 Locator TLV is
introduced to advertise Locators and End SIDs associated with each
locator. This TLV shares the sub-TLV space defined for TLVs 135, 236
and 237.
This document adopts the Anycast Flag (A-flag). In addition, this
document defines a new flag in SRv6 End SID sub-TLV. The format is
as follows:
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Endpoint Behavior |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Anycast SID (128 bits) . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Anycast SID (cont . . .) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Anycast SID (cont . . .) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Anycast SID (cont . . .) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-sub-tlv-len| sub-sub-TLVs(variable). . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Anycast SID Format
Type: 5 (defined in [I-D.draft-ietf-lsr-isis-srv6-extensions]).
Length: Variable.
Flags: 8 bits.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|A|U|U|U|U|U|U|U|
+-+-+-+-+-+-+-+-+
Figure 4: Anycast Flag
Li, et al. Expires September 24, 2021 [Page 5]
Internet-DraAnycast SID for Flexible and Robust Service in S March 2021
U: Unused and for future use. Must be 0 on transmission and ignored
on receipt.
A: Anycast flag, set when the SRv6 End SID sub-TLV carries the
Anycast SIDs.
Endpoint Behavior: 16 bits, code point that identifies the service
functions.
Anycast SID: 128 bits.
Sub-sub-TLV-length: defined in
[I-D.draft-ietf-lsr-isis-srv6-extensions].
Sub-sub-TLVs: defined in [I-D.draft-ietf-lsr-isis-srv6-extensions].
The Anycast SID MUST be a subnet of the associated Locator. Anycast
SIDs which are NOT a subnet of the associated locator MUST be
ignored.
Multiple Anycast SIDs MAY be associated with the same locator when a
execution endpoint holds multiple service functions. In cases where
the number of SRv6 End SID sub-TLVs exceeds the capacity of a single
TLV, multiple Locator TLVs for the same locator MAY be advertised.
Other details are defined in
[I-D.draft-ietf-lsr-isis-srv6-extensions].
4. Data Plane
This document requires no data plane format extensions to SRv6 and
the Anycast SID has no differences with other SIDs. Anycast SIDs
stay together with other SIDs in the SRH and the SID list can not
only steer the packet along a TE path but also specifies the service
functions that should process the packet.
The Anycast SIDs are advertised by control plane and instantiated in
the local FIB.When a SRv6-capable node receives an IPv6 packet, it
performs a long-prefix-match lookup on the packets destination
address. This lookup may return a FIB entry that represents a
locally instantiated SID. If this matched SID is Anycast SID, the
node should process the packet with the service function identified
by the Anycast SID.
5. Illustration
Li, et al. Expires September 24, 2021 [Page 6]
Internet-DraAnycast SID for Flexible and Robust Service in S March 2021
5.1. Usecase1 migration of service function
As illustrated in Figure 5, a SRv6-based service function chain needs
to go through SF1, SF2 and SF3. At the beginning, SF1, SF2 and SF3
are provided on node 1, node 2 and node 4. Then, SF2 is migrated to
node 3 and the flow should change the path. In addition to SRv6 SIDs
A1::B1, A2::B2, A3::B2 and A4::B3 on the four nodes, they also have
Anycast SIDs instantiated locally and advertised by the control
plane.
If original SRv6 is used, the SRH is (A1::B1, A2::B2, A4::B3) before
the migration and (A1::B1, A2::B2, A4::B3) after the migration. The
ingress node should change the encapsulation strategies under control
of the controller and re-encapsulate the packets.
If Anycast SID is used, the SRH is (A::B1, A::B2, A::B3) before and
after migration. No changes to the SRH is needed. Node 2 withdraws
the route of A::B2 and Node 3 advertises A::B2. Then the packets are
forwarded based on the route of A::B2/128.
+-+-+ +-+-+ +-+-+
|SF1| |SF2|**** |SF3|
+-+-+ +-+-+ * +-+-+
| A::B2 | * |
| +-+-+-+-+ * |
| +-+-+-+-+node 2 +-*-+-+-+ |
+-+-+-+-+ | | +-+-+-+-+ * | | +-+-+-+-+
|ingress| +-+-+-+-+ A2::B2 * +-+-+-+-+ |egress |
| node +-+-+-+node 1 | * |node 4 +-+-+-+ node |
| | +-+-+-+-+ A3::B2 * +-+-+-+-+ | |
+-------+ A::B1 | +-+-+-+-+ * | A::B3 +-+-+-+-+
A1::B1+-+-+-+-+node 3 +-*-+-+-+ A4::B3
+-+-^-+-+ *
* *
*******
Figure 5: Illustration topology for usecase1
5.2. Usecase2 failover of service function
As illustrated in Figure 6, a SRv6-based service function chain needs
to go through SF1, SF2 and SF3. At the beginning, SF1, SF2 and SF3
are provided on node 1, node 2 and node 4. Suddenly, node 2 is down
and SF2 should be provided by node 3. The flow should change the
path. In addition to SRv6 SIDs A1::B1, A2::B2, A3::B2 and A4::B3 on
the four nodes, they also have Anycast SIDs instantiated locally and
advertised by the control plane.
Li, et al. Expires September 24, 2021 [Page 7]
Internet-DraAnycast SID for Flexible and Robust Service in S March 2021
If original SRv6 is used, the SRH is (A1::B1, A2::B2, A4::B3) before
failover and (A1::B1, A2::B2, A4::B3) after failover. The ingress
node should change the encapsulation strategies under control of the
controller and re-encapsulate the packets.
If Anycast SID is used, the SRH is (A::B1, A::B2, A::B3) before and
after failover. No changes to the SRH is needed. Node 2 withdraws
the route of A::B2 and Node 3 advertises A::B2. The FIB on node 1 is
updated that the packet destinated to A::B2/128 should be forwarded
to node 3. Then the packets are forwarded based on the route of
A::B2/128.
+-+-+ +-+-+ +-+-+
|SF1| |SF2|**** |SF3|
+-+-+ +-+-+ * +-+-+
| A::B2 | * |
| +-+-+-+-+ * |
| +-+-+-+-+node 2 +-*-+-+-+ |
+-+-+-+-+ | | +-+-+-+-+ * | | +-+-+-+-+
|ingress| +-+-+-+-+ A2::B2 * +-+-+-+-+ |egress |
| node +-+-+-+node 1 | * |node 4 +-+-+-+ node |
| | +-+-+-+-+ A3::B2 * +-+-+-+-+ | |
+-------+ A::B1 | +-+-+-+-+ * | A::B3 +-+-+-+-+
A1::B1+-+-+-+-+node 3 +-*-+-+-+ A4::B3
+-+-+-+-+ *
A::B2 | *
+-+-+ *
|SF2|<***
+-+-+
Figure 6: Illustration topology for usecase2
6. Security Considerations
TBD
7. IANA Considerations
IANA is requested to allocated one bit in SRv6 End SID sub-TLV Flags
to indicate that the sub-TLV carries Anycast SIDs.
8. References
8.1. Normative References
[I-D.draft-ietf-lsr-isis-srv6-extensions]
Peter, P. and C. Clarence, "IS-IS Extension to Support
Segment Routing over IPv6 Dataplane", 2021.
Li, et al. Expires September 24, 2021 [Page 8]
Internet-DraAnycast SID for Flexible and Robust Service in S March 2021
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
8.2. Informative References
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513,
DOI 10.17487/RFC3513, April 2003,
<https://www.rfc-editor.org/info/rfc3513>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
[RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and
U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4
and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794,
March 2016, <https://www.rfc-editor.org/info/rfc7794>.
Li, et al. Expires September 24, 2021 [Page 9]
Internet-DraAnycast SID for Flexible and Robust Service in S March 2021
Authors' Addresses
Taixin Li
CNIC, CAS
No. 4 Zhongguancun South 4th Street
Beijing 100190
China
Email: txli@cnic.cn
Xu Zhou
CNIC, CAS
No. 4 Zhongguancun South 4th Street
Beijing 100190
China
Email: zhouxu@cnic.cn
Zhe Chen
Huawei Technologies
No. 156 Beiqing Rd
Beijing 100095
China
Email: chenzhe17@huawei.com
Yihao Jia
Huawei Technologies
No. 156 Beiqing Rd
Beijing 100095
China
Email: jiayihao@huawei.com
Li, et al. Expires September 24, 2021 [Page 10]