LSR Working Group Yao. Liu
Internet-Draft Zheng. Zhang
Intended status: Standards Track ZTE Corporation
Expires: January 11, 2021 July 10, 2020
IGP Extensions for Segment Routing Service Segment
draft-lz-lsr-igp-sr-service-segments-02
Abstract
This document defines extensions to the link-state routing protocols
(IS-IS and OSPF) in order to carry service segment information via
IGP.
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 11, 2021.
Copyright Notice
Copyright (c) 2020 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.
Liu & Zhang Expires January 11, 2021 [Page 1]
Internet-Draft IGP for Service Segment July 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IGP Extensions for Service Segments . . . . . . . . . . . . . 3
2.1. IS-IS Extensions . . . . . . . . . . . . . . . . . . . . 3
2.2. OSPFv2 and OSPFv3 Extensions . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Normative References . . . . . . . . . . . . . . . . . . 7
5.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
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 network topology is shown in figure 1.
SR-C
|
|
A----1----2----3----4----5----B
| |
| |
S1 S2 proxy----S2
Figure 1: Network with Services
Liu & Zhang Expires January 11, 2021 [Page 2]
Internet-Draft IGP for Service Segment July 2020
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.
SR Controller (SR-C) is connected to node 1, but may be attached to
any node 1-5 in the network.
SR-C is capable of receiving BGP-LS updates to discover topology, and
calculating constrained paths between 1 and 5.
Node 1 can use the BGP-LS extensions
[I-D.ietf-spring-sr-service-programming] to advertise the service
segment information to the SR-C, but it must get the information from
other nodes at first.
This document proposes extensions for IGP to advertise service
segment information so that there is only one SR node needed per
Autonomous System to be connected with the SR-C through BGP-LS to
advertise the information to it.
This extension works for both SR-MPLS and SRv6.
2. IGP Extensions for Service Segments
After an SFF like node 2 or node 4 get the service segment
information, it needs to advertise the information to other SR nodes
in the domain through IGP.
How can SFFs like node 2 and node 4 get the service segment
information from S1 and S2 proxy will be discussed further.
There may be other alternate mechanisms and are outside of scope of
this document.
2.1. IS-IS Extensions
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 :
Liu & Zhang Expires January 11, 2021 [Page 3]
Internet-Draft IGP for Service Segment July 2020
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2:Service Chaining (SC) TLV
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Service Info Field
Liu & Zhang Expires January 11, 2021 [Page 4]
Internet-Draft IGP for Service Segment July 2020
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) |
+---------------------------------------+
Figure 4:Opaque Metadata(OM) TLV
Liu & Zhang Expires January 11, 2021 [Page 5]
Internet-Draft IGP for Service Segment July 2020
2.2. OSPFv2 and OSPFv3 Extensions
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5:Service Chaining (SC) TLV
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.
Liu & Zhang Expires January 11, 2021 [Page 6]
Internet-Draft IGP for Service Segment July 2020
+---------------------------------------+
| Type (2 octet) |
+---------------------------------------+
| Length (2 octet) |
+---------------------------------------+
| Opaque Type (2 octet) |
+---------------------------------------+
| Flags (1 octet) |
+---------------------------------------+
| Value (variable) |
+---------------------------------------+
Figure 6:Opaque Metadata(OM) TLV
3. Security Considerations
Procedures and protocol extensions defined in this document do not
affect the IS-IS and OSPF security model
4. IANA Considerations
TBD
5. References
5.1. Normative References
[I-D.dawra-idr-bgp-ls-sr-service-segments]
Dawra, G., Filsfils, C., Talaulikar, K., Clad, F.,
daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B.,
Elmalky, H., Xu, X., Guichard, J., and C. Li, "BGP-LS
Advertisement of Segment Routing Service Segments", draft-
dawra-idr-bgp-ls-sr-service-segments-03 (work in
progress), January 2020.
[I-D.ietf-lsr-isis-srv6-extensions]
Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
Z. Hu, "IS-IS Extension to Support Segment Routing over
IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-08
(work in progress), April 2020.
[I-D.ietf-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
Henderickx, W., and S. Salsano, "Service Programming with
Segment Routing", draft-ietf-spring-sr-service-
programming-02 (work in progress), March 2020.
Liu & Zhang Expires January 11, 2021 [Page 7]
Internet-Draft IGP for Service Segment July 2020
[I-D.li-ospf-ospfv3-srv6-extensions]
Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak,
"OSPFv3 Extensions for SRv6", draft-li-ospf-
ospfv3-srv6-extensions-07 (work in progress), November
2019.
[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>.
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", RFC 8665,
DOI 10.17487/RFC8665, December 2019,
<https://www.rfc-editor.org/info/rfc8665>.
[RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions
for Segment Routing", RFC 8666, DOI 10.17487/RFC8666,
December 2019, <https://www.rfc-editor.org/info/rfc8666>.
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
Extensions for Segment Routing", RFC 8667,
DOI 10.17487/RFC8667, December 2019,
<https://www.rfc-editor.org/info/rfc8667>.
5.2. Informative References
[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>.
Authors' Addresses
Liu Yao
ZTE Corporation
No. 50 Software Ave, Yuhuatai Distinct
Nanjing
China
Email: liu.yao71@zte.com.cn
Liu & Zhang Expires January 11, 2021 [Page 8]
Internet-Draft IGP for Service Segment July 2020
Zhang Zheng
ZTE Corporation
No. 50 Software Ave, Yuhuatai Distinct
Nanjing
China
Email: zzhang_ietf@hotmail.com
Liu & Zhang Expires January 11, 2021 [Page 9]