| Internet-Draft | IGP for Service Segment | January 2021 |
| Liu, et al. | Expires 25 July 2021 | [Page] |
This document defines extensions to the link-state routing protocols (IS-IS and OSPF) in order to carry service segment information via IGP.¶
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 25 July 2021.¶
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.¶
Segments are introduced in the SR architecture [RFC8402]. Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments".¶
Service Function Chaining (SFC) [RFC7665] provides support for the creation of composite services that consist of an ordered set of Service Functions (SF) that are to be applied to packets and/or frames selected as a result of classification.¶
[I-D.ietf-spring-sr-service-programming] describes how a service can be associated with a SID and how to achieve service funtion chaining in SR-enabled MPLS and IPv6 networks. It also defines SR-aware and SR-unaware services. For a SR-unaware service ,there has to be a SR proxy handling the SR processing on behalf of the service .¶
[I-D.dawra-idr-bgp-ls-sr-service-segments] propose extensions to BGP-LS for Service Chaining to distribute the service segment information to SR Controller.¶
The reference network topology is shown in figure 1.¶
SR-C
A----1----2----3----4----5----B
| |
| |
S1 S2
Node 1-5 are nodes capital of segment routing. A and B are two end hosts. S1 is an SR-aware Service. S2 is an SR-unaware Service and node 4 act as an SR proxy. The path from A to B needs to pass through service function S1 and S2. SR Controller (SR-C) is capable of receiving BGP-LS updates to discover topology, and calculating constrained paths between 1 and 5. To provision and maintain service function path, the SR-C needs to collect the SID-related service information as well.¶
If the service segment information can only be transmitted through BGP-LS, the BGP protocol needs to be enabled on all the service function nodes or SFFs, and BGP neighbors should be established between these nodes and the SR-C or the node selected to have a BGP session with the controller.¶
A common scenario is that IGP is enabled on each node in the network to distributed SIDs and SID-related information(e.g reachability, behavior, structure,etc) within the domain and a small amout of nodes are connected to the controller/PCE via BGP-LS to report SID-related information along with the topology. This document proposes extensions for IGP to advertise service segment information along with SIDs to support such scenario.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
SFC: Service Function Chain¶
SFF: Service Function Forwarder¶
SF: Service Function¶
SFP: Service Function Path¶
If an service function node like S1 supports IGP function, it advertises the service information to other SR nodes through IGP itself. Otherwise, SFFs like node 2 or node 4 are responsible to advertise the service information through IGP. How can SFFs get the service segment information from SFs is outside of scope of this document.¶
This document introduces new sub-sub-TLVs for SRv6 End SID sub-TLV [I-D.ietf-lsr-isis-srv6-extensions] and Prefix Segment Identifier (Prefix-SID) Sub-TLV [RFC8667] for SR-MPLS to associate the Service SID Value with Service-related Information.¶
One of the new TLVs is Service Chaining (SC) TLV, the TLV is defined 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 | Service Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Traffic Type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
Type: 8 bit field. TBD¶
Length: 8 bit field indicating the length of the remainder of the TLV¶
The Flags, Traffic Type and RESERVED fields are the same as in the SC TLV defined in [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2.¶
Flags: 8 bit field. Bits SHOULD be 0 on transmission and MUST be ignored on reception.¶
Traffic Type: 8 Bit field. A bit to identify if Service is IPv4 OR IPv6 OR L2 Ethernet Capable.¶
Bit 0(LSB): Set to 1 if Service is IPv4 Capable¶
Bit 1: Set to 1 if Service is IPv6 Capable¶
Bit 2: Set to 1 if Service is Ethernet Capable¶
RESERVED: 16bit field. SHOULD be 0 on transmission and MUST be ignored on reception.¶
Service Info: 16-bits field. The right most 12 bits categorize the Service Type: (such as "Firewall", "Classifier" etc).¶
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P FLAG| Service Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first 4 bits are P FLAG which is used to indicate the SR proxy type with the following values:¶
0000:SR-aware function.¶
0001:Static proxy.¶
0010:Dynamic proxy.¶
0011:Masquerading proxy(for SRv6 only).¶
0100:Shared memory proxy.¶
Other values are reserved.¶
The P FLAG is mainly defined for SR-MPLS.¶
In SRv6, although the SR proxy type can be represented by the END functions[I-D.ietf-spring-sr-service-programming] which can be advertised in Endpoint Behavior field of End SID sub-TLV [I-D.ietf-lsr-isis-srv6-extensions], there may be situations that the proxy with certain type cannot be associated with a network programming function(for example, Shared memory proxy),or an user want to define a new type of proxy for private use, or the SR proxy node does not support network programming, so the P flag is still useful.¶
In the IS-IS notification message, when both SR proxy END function and P FLAG exist, the proxy type represented by P FLAG shall prevail.¶
Another Optional Opaque Metadata(OM) TLV is defined in figure 4. The definition and structure are the same as the OM TLV defined in [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2.¶
+---------------------------------------+
| Type (1 octet) |
+---------------------------------------+
| Length (1 octet) |
+---------------------------------------+
| Opaque Type (2 octet) |
+---------------------------------------+
| Flags (1 octet) |
+---------------------------------------+
| Value (variable) |
+---------------------------------------+
This document introduces new sub-sub-TLVs for SRv6 End SID sub-TLV [I-D.li-ospf-ospfv3-srv6-extensions] and Prefix-SID Sub-TLV [RFC8665] [RFC8665] for SR-MPLS to associate the Service SID Value with Service-related Information.¶
One of the new TLVs is Service Chaining (SC) TLV,¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Info | Flags | Traffic Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
Type: 16 bit field. TBD¶
Length: 16 bit field indicating the length of the remainder of the TLV¶
Flags, Traffic Type and RESERVED are the same as that in SC TLV defined in [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2.¶
The definition and use principle of the Service Type field is the same as that defined in the IS-IS extension above.¶
Another Optional Opaque Metadata(OM) TLV is defined in figure 6. The definition and structure are the same as the OM TLV defined in [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2.¶
+---------------------------------------+
| Type (2 octet) |
+---------------------------------------+
| Length (2 octet) |
+---------------------------------------+
| Opaque Type (2 octet) |
+---------------------------------------+
| Flags (1 octet) |
+---------------------------------------+
| Value (variable) |
+---------------------------------------+
Procedures and protocol extensions defined in this document do not affect the IS-IS and OSPF security model¶
TBD¶