LSR P. Shaofu
Internet-Draft C. Ran
Intended status: Standards Track ZTE Corporation
Expires: September 10, 2020 March 9, 2020
Algorithm Related IGP-Adjacency SID Advertisement
draft-peng-lsr-algorithm-related-adjacency-sid-00
Abstract
Segment Routing architecture supports the use of multiple routing
algorithms, i.e, different constraint-based shortest-path
calculations can be supported. There are two standard algorithms:
SPF and Strict-SPF, defined in Segment Routing architecture. There
are also other user defined algorithms according to Flex-algo
applicaiton. However, an algorithm identifier is often included as
part of a Prefix-SID advertisement, that maybe not satisfy some
scenarios where multiple algorithm share the same link resource.
This document will complement that the algorithm identifier can be
also included as part of a Adjacency-SID advertisement
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 10, 2020.
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
Shaofu & Ran Expires September 10, 2020 [Page 1]
Internet-Draft algo-related adj-sid March 2020
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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Adjacency Segment Identifier per Algorithm . . . . . . . . . 3
3.1. ISIS Adjacency Segment Identifier per Algorithm . . . . . 3
3.1.1. ISIS Adjacency Segment Identifier (Adj-SID) per
Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 4
3.1.2. ISIS Adjacency Segment Identifier (LAN-Adj-SID) per
Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 4
3.2. OSPF Adjacency Segment Identifier per Algorithm . . . . . 5
3.2.1. OSPF Adj-SID Sub-TLV . . . . . . . . . . . . . . . . 6
3.2.2. OSPF LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . 6
3.3. OSPFv3 Adjacency Segment Identifier per Algorithm . . . . 7
3.3.1. OSPFv3 Adj-SID Sub-TLV . . . . . . . . . . . . . . . 7
3.3.2. OSPFv3 LAN Adj-SID Sub-TLV . . . . . . . . . . . . . 8
4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Segment Routing architecture [RFC8402] supports the use of multiple
routing algorithms, i.e, different constraint-based shortest-path
calculations can be supported. There are two standard algorithms,
i.e, SPF and Strict-SPF, that defined in Segment Routing
architecture. For SPF, the packet is forwarded along the well known
ECMP-aware Shortest Path First (SPF) algorithm employed by the IGPs.
However, it is explicitly allowed for a midpoint to implement another
forwarding based on local policy. For Strict Shortest Path First
(Strict-SPF), it mandates that the packet be forwarded according to
the ECMP-aware SPF algorithm and instructs any router in the path to
ignore any possible local policy overriding the SPF decision.
There are also other user defined algorithms according to IGP Flex
Algorithm [I-D.ietf-lsr-flex-algo]. IGP Flex Algorithm proposes a
solution that allows IGPs themselves to compute constraint based
paths over the network, and it also specifies a way of using Segment
Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the
Shaofu & Ran Expires September 10, 2020 [Page 2]
Internet-Draft algo-related adj-sid March 2020
constraint-based paths. It specifies a set of extensions to ISIS,
OSPFv2 and OSPFv3 that enable a router to send TLVs that identify (a)
calculation-type, (b) specify a metric-type, and (c )describe a set
of constraints on the topology, that are to be used to compute the
best paths along the constrained topology. A given combination of
calculation-type, metric-type, and constraints is known as an FAD
(Flexible Algorithm Definition).
However, an algorithm identifier is often included as part of a
Prefix-SID advertisement, that maybe not satisfy some scenarios where
multiple algorithm share the same link resource. For example, a SR-
TE policy may be instantiated within specific Flex-algo plane, i.e.,
the SID list requires to include algorithm related SIDs. An
algorithm-unware Adjacency-SID included in the SID list can just
steer the packet towards the link, but can not apply different QoS
policy for different algorithm. Another example is that the TI-LFA
backup path computed in Flex-algo plane may also contain an
algorithm-unware Adjacency-SID, which maybe also used in other SR-TE
instance.
This document will complement that the algorithm identifier can be
also included as part of an Adjacency-SID advertisement for SR-MPLS.
2. Requirements Language
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.
3. Adjacency Segment Identifier per Algorithm
3.1. ISIS Adjacency Segment Identifier per Algorithm
[RFC8667] describes the IS-IS extensions that need to be introduced
for Segment Routing operating on an MPLS data plane. It defined
Adjacency Segment Identifier (Adj-SID) sub-TLV advertised with TLV-
22/222/23/223/141, and Adjacency Segment Identifier (LAN-Adj-SID)
Sub-TLV advetised with TLV-22/222/23/223. Accordingly, this document
defines two new optional Sub-TLVs, "ISIS Adjacency Segment Identifier
(Adj-SID) per Algorithm Sub-TLV" and "ISIS Adjacency Segment
Identifier (LAN-Adj-SID) per Algorithm Sub-TLV".
Shaofu & Ran Expires September 10, 2020 [Page 3]
Internet-Draft algo-related adj-sid March 2020
3.1.1. ISIS Adjacency Segment Identifier (Adj-SID) per Algorithm Sub-
TLV
ISIS Adjacency Segment Identifier (Adj-SID) per Algorithm Sub-TLV has
the following format:
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 | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ISIS Adjacency Segment Identifier (Adj-SID) per Algorithm
Format
where:
Type: TBD1.
Length: 6 or 7 depending on size of the SID.
Flags: Refer to Adjacency Segment Identifier (Adj-SID) sub-TLV.
Weight: Refer to Adjacency Segment Identifier (Adj-SID) sub-TLV.
Algorithm: The Algorithm field contains the identifier of the
algorithm the router uses to apply algorithm specific QoS policy
configured on the adjacency.
SID/Label/Index: Refer to Adjacency Segment Identifier (Adj-SID) sub-
TLV.
For a P2P link, an SR-capable router MAY allocate different Adj-SID
for different algorithm, if this link will join different algorithm
related plane.
3.1.2. ISIS Adjacency Segment Identifier (LAN-Adj-SID) per Algorithm
Sub-TLV
ISIS Adjacency Segment Identifier (LAN-Adj-SID) per Algorithm Sub-TLV
has the following format:
Shaofu & Ran Expires September 10, 2020 [Page 4]
Internet-Draft algo-related adj-sid March 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 | Flags | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor System-ID (ID length octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ISIS Adjacency Segment Identifier (LAN-Adj-SID) per
Algorithm Format
where:
Type: TBD2.
Length: Variable.
Flags: Refer to Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV.
Weight: Refer to Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV.
Algorithm: The Algorithm field contains the identifier of the
algorithm the router uses to apply algorithm specific QoS policy
configured on the adjacency.
SID/Label/Index: Refer to Adjacency Segment Identifier (LAN-Adj-SID)
Sub-TLV.
For a broadcast link, an SR-capable router MAY allocate different
Adj-SID for different algorithm, if this link will join different
algorithm related plane.
3.2. OSPF Adjacency Segment Identifier per Algorithm
[RFC8665] describes the OSPF extensions that need to be introduced
for Segment Routing operating on an MPLS data plane. It defined Adj-
SID Sub-TLV and LAN Adj-SID Sub-TLV advertised with Extended Link TLV
defined in [RFC7684]. This document extends these two Sub-TLVs to
carry the specific algorithm.
Shaofu & Ran Expires September 10, 2020 [Page 5]
Internet-Draft algo-related adj-sid March 2020
3.2.1. OSPF Adj-SID Sub-TLV
The existing Adj-SID Sub-TLV has the following format:
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 | Algorithm | MT-ID | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) |
+---------------------------------------------------------------+
Figure 3: OSPF Adj-SID Format
where:
Algorithm: The new Algorithm field contains the identifier of the
algorithm the router uses to apply algorithm specific QoS policy
configured on the adjacency.
For a P2P link, an SR-capable router MAY allocate different Adj-SID
for different algorithm, if this link will join different algorithm
related plane.
3.2.2. OSPF LAN Adj-SID Sub-TLV
The existing LAN Adj-SID Sub-TLV has the following format:
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 | Algorithm | MT-ID | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) |
+---------------------------------------------------------------+
Figure 4: OSPF LAN Adj-SID Format
Shaofu & Ran Expires September 10, 2020 [Page 6]
Internet-Draft algo-related adj-sid March 2020
where:
Algorithm: The new Algorithm field contains the identifier of the
algorithm the router uses to apply algorithm specific QoS policy
configured on the adjacency.
For a broadcast link, an SR-capable router MAY allocate different
Adj-SID for different algorithm, if this link will join different
algorithm related plane.
3.3. OSPFv3 Adjacency Segment Identifier per Algorithm
[RFC8666] describes the OSPFv3 extensions that need to be introduced
for Segment Routing operating on an MPLS data plane. It defined Adj-
SID Sub-TLV and LAN Adj-SID Sub-TLV advertised with Router-Link TLV
as defined in [RFC8362]. This document extends these two Sub-TLVs to
carry the specific algorithm.
3.3.1. OSPFv3 Adj-SID Sub-TLV
The existing Adj-SID Sub-TLV has the following format:
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 | Weight | Algorithm | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) |
+---------------------------------------------------------------+
Figure 5: OSPFv3 Adj-SID Format
where:
Algorithm: The new Algorithm field contains the identifier of the
algorithm the router uses to apply algorithm specific QoS policy
configured on the adjacency.
For a P2P link, an SR-capable router MAY allocate different Adj-SID
for different algorithm, if this link will join different algorithm
related plane.
Shaofu & Ran Expires September 10, 2020 [Page 7]
Internet-Draft algo-related adj-sid March 2020
3.3.2. OSPFv3 LAN Adj-SID Sub-TLV
The existing LAN Adj-SID Sub-TLV has the following format:
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 | Weight | Algorithm | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) |
+---------------------------------------------------------------+
Figure 6: OSPFv3 LAN Adj-SID Format
where:
Algorithm: The new Algorithm field contains the identifier of the
algorithm the router uses to apply algorithm specific QoS policy
configured on the adjacency.
For a broadcast link, an SR-capable router MAY allocate different
Adj-SID for different algorithm, if this link will join different
algorithm related plane.
4. Operations
TBD
5. IANA Considerations
TBD
6. Security Considerations
There are no new security issues introduced by the extensions in this
document.
7. Acknowledgements
TBD
Shaofu & Ran Expires September 10, 2020 [Page 8]
Internet-Draft algo-related adj-sid March 2020
8. Normative References
[I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-06 (work in progress), February 2020.
[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>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007,
<https://www.rfc-editor.org/info/rfc4915>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <https://www.rfc-editor.org/info/rfc7684>.
[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>.
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
F. Baker, "OSPFv3 Link State Advertisement (LSA)
Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
2018, <https://www.rfc-editor.org/info/rfc8362>.
[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>.
Shaofu & Ran Expires September 10, 2020 [Page 9]
Internet-Draft algo-related adj-sid March 2020
[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>.
[RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri,
M., and E. Aries, "Advertising Layer 2 Bundle Member Link
Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668,
December 2019, <https://www.rfc-editor.org/info/rfc8668>.
Authors' Addresses
Peng Shaofu
ZTE Corporation
No.68 Zijinghua Road, Yuhuatai District
Nanjing
China
Email: peng.shaofu@zte.com.cn
Chen Ran
ZTE Corporation
No.50 Software Avenue, Yuhuatai District
Nanjing
China
Email: chen.ran@zte.com.cn
Shaofu & Ran Expires September 10, 2020 [Page 10]