Internet-Draft IGP Flex-Algorithm with Common Address July 2022
Hu, et al. Expires 8 January 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-hu-lsr-igp-ca-flex-algorithm-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
Z. Hu
Huawei
G. Xu
Huawei
J. Dong
Huawei

IGP Flexible Algorithm with Common Address

Abstract

An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute constraint-based paths. IGP Flex-Algorithm can be used with Segment Routing (SR) or IP data plane. When used with SR data plane, Flex-Algorithm requires to allocate algorithm specific Prefix Segment Identifiers (SIDs) or algorithm specific SRv6 Locators. When used with IP data plane, Flex-Algorithm requires to allocate algorithm specfic IPv4 or IPv6 prefixes. This increases the complexity and overhead of managing, advertising and maintaining additional SR SIDs, SRv6 Locators and IPv4 or IPv6 prefixes, which may not be affordable to some networks and network devices.

This document extends IGP Flex-Algorithm to allow the use of common SR SIDs, SRv6 Locators and IP prefixes among multiple Flex-Algorithms.

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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

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 8 January 2023.

Table of Contents

1. Introduction

The IGP Flexible Algorithm (Flex-Algorithm) [I-D.ietf-lsr-flex-algo] specifies a way of computing a constraint-based path using IGP. IGP Flex-Algorithm can be used with Segment Routing (SR) or IP data plane . When used with SR data plane, Flex-Algorithm requires to allocate algorithm specific Prefix Segment Identifiers (SIDs) [RFC8402] or algorithm specific SRv6 Locators [RFC8986]. When used with IP data plane, Flex-Algorithm requires to allocate algorithm specfic IPv4 or IPv6 prefixes [I-D.ietf-lsr-ip-flexalgo]. The current Flex-Algorithm mechanism increases the complexity and overhead of managing, advertising and maintaining additional SR SIDs, SRv6 Locators and IPv4 prefixes, which may not be affordable to some networks and devices.

For example, [I-D.ietf-lsr-isis-srv6-extensions] and [I-D.ietf-lsr-ospfv3-srv6-extensions] define the IGP Extensions to support SRv6. For each Flex-Algorithm, separate SRv6 locators, End SIDs and End.X SIDs needs to be allocated and advertised. As the number of Flex-Algorithm increases, it the pressure on the IGP would increase accordingly.

In addition, SInce the SRv6 VPN SIDs are always associated with the Flex-Algorithm to which the SRv6 Locator is allocated, it is impossible to steer different service flows of an SRv6 VPN using different Flex-Algorithm.

To overcome the above issues and limitation with IGP Flex-Algo, this document defines the Common Address (CA) Flex-Algorithm extensions to allow the use of the same set of SR SIDs, SRv6 Locators, or IP prefixes among multiple Flex-Algorithms. Here the term Common Address (CA) refers to the common set of SR SIDs, SRv6 Locators or IP prefixes respectively for SR or IP data plane.

Based on the CA Flex-Algo mechanism, constrainet-based path computation is done for each Flex-Algorithm, and the routing entries for each Flex-Algorithm is maintained in a separate Routing Information Base (RIB). For packet forwarding, some additional data plane field in packet header is needed to select the correct RIB for the incoming packet lookup to make the forwarding decision. [I-D.li-6man-topology-id] proposes the IPv6 extensions to carry the topology and/or Algorithm ID in the data plane. The extensions to other data plane are for further study. Such data plane mechanisms together with the control plane extensions in this document provides a CA Flex-Algo solution.

2. Advertising Flex-Algorithm Definitions

To guarantee loop free forwarding, all routers that participate in a Flex-Algorithm MUST agree on the Flex-Algorithm Definition (FAD).

The advertisement of FAD for CA Flex-Algorithm is not changed. Selected nodes within the IGP domain MUST advertise FADs as described in Sections 5, 6, and 7 of [I-D.ietf-lsr-flex-algo].

3. Advertising CA Flex-Algorithm Participation

When a router is configured to support a particular CA Flex-Algorithm, we say it is participating in that CA Flex-Algorithm.To guarantee the presence of the application specific forwarding state associated with a particular Flex-Algorithm, a router MUST advertise its participation for a particular Flex-Algorithm.

The following sections describe how the CA Flex-Algorithm participation is advertised in IGP protocols.

3.1. The IS-IS CA Algorithm Sub-TLV

The ISIS [ISO10589] CA Algorithm Sub-TLV is a sub-TLV of the IS-IS Router Capability TLV [RFC7981] and 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    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Algorithm 1   |  Algorithm 2  | Algorithm ... |  Algorithm n  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IS-IS CA Algorithm Sub-TLV

Type: TBD

Length: Variable

Algorithm (1 octet): Value from 128 to 255.

The CA Algorithm Sub-TLV MUST be propagated throughout the level and MUST NOT be advertised across level boundaries. Therefore, the S bit in the Router Capability TLV, in which the CA Algorithm Sub-TLV is advertised, MUST NOT be set.

The CA Algorithm Sub-TLV is optional. It MUST NOT be advertised more than once at a given level. A router receiving multiple CA Algorithm sub-TLVs from the same originator MUST select the first advertisement in the lowest-numbered LSP and subsequent instances of the CA Algorithm Sub-TLV MUST be ignored.

The CA Flex-Algorithm participation advertised in the IS-IS CA Algorithm Sub-TLV is topology independent. When a router advertises participation in the IS-IS CA Algorithm Sub-TLV, the participation applies to all topologies in which the advertising node participates.

3.2. The OSPFv3 CA Algorithm Sub-TLV

The CA Algorithm TLV is a top-level TLV of the OSPFv3 Router Information Opaque LSA [RFC7770] and 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    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Algorithm 1   |  Algorithm 2  | Algorithm ... |  Algorithm n  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: OSPFv3 CA Algorithm TLV

Type: TBD

Length: Variable

Algorithm (1 octet): Value from 128 to 255.

When multiple of the CA Algorithm TLVs are received from a given router, the receiver MUST use the first occurrence of the TLV in the OSPFv3 Router Information Opaque LSA. If the CA Algorithm TLV appears in multiple Router Information Opaque LSAs that have different flooding scopes, the CA Algorithm TLV in the Router Information Opaque LSA with the area-scoped flooding scope MUST be used. If the CA Algorithm TLV appears in multiple Router Information Opaque LSAs that have the same flooding scope, the CA Algorithm TLV in the Router Information (RI) Opaque LSA with the numerically smallest Instance ID MUST be used and subsequent instances of the CA Algorithm TLV MUST be ignored.

The RI LSA can be advertised at any of the defined opaque flooding scopes (link, area, or Autonomous System (AS)). For the purpose of CA Algorithm TLV advertisement, area-scoped flooding is REQUIRED.

4. SRv6 Locators for CA Flex-Algorithm

The SRv6 locator TLV is defined in [I-D.ietf-lsr-isis-srv6-extensions] and [I-D.ietf-lsr-ospfv3-srv6-extensions], which contains an algorithm and indicates that the locator only performs path calculation in this algorithm plane.

This document defines a new flag in the SRv6 Locator TLV to indicate that the locator has the ability to be used for path calculations in multiple CA Flex-Algorithms planes. The position of this flag is BIT(1) in IS-IS and BIT(2) in OSPFv3.

This bit is set in the Flags in the Locator TLV in which the value of the algorithm field is 0. When the algorithm is non-zero, the flag MUST NOT be set.

C-Flag: CA Flex-Algorithm Flag.

A receiver do not support machanisms defined in this document MUST ignore this flag.

5. SRv6 Adjacency SIDs for CA Flex-Algorithm

The SRv6 SIDs associated with Adjacencies is defined in [I-D.ietf-lsr-isis-srv6-extensions] and [I-D.ietf-lsr-ospfv3-srv6-extensions] and is explicitly allocated by the locator.

A new Flag calle is defined to specify that the locator associated with the adjacent SID has the C flag.

C-Flag: CA Flex-Algorithm Flag.

The position of this flag is BIT(4) in IS-IS and OSPFv3.

This bit is set in Flags in SRv6 END.X and LAN END.X SID TLV in which the value of the algorithm field is 0. When the Locator corresponding to the End.X SID does not have the C flag set, the C flag in the END.X and LAN END.X SID TLV MUST NOT be set.

A receiver do not support machanisms defined in this document MUST ignore this flag.

6. Calculating paths with CA Flex-Algorithm

The CA Flex-Algorthm can considered as yet another data-plane of the Flex-Algorithm as described [I-D.ietf-lsr-flex-algo].

Participation for the CA Flex-Algorithm is signalled as described in Section 3 and is specific to the CA Flex-Algorithm data-plane.

The calculation of CA Flex-Algorithm paths follows what is described in [I-D.ietf-lsr-flex-algo]. This computation uses the CA Flex- Algorithm data-plane participation and is independent of the Flex-Algorithm calculation done for native SR or IP data plane.

The CA Flex-Algorithm data-plane only considers the participating nodes during the Flex-Algorithm calculation. When computing paths for a given CA Flex-Algorithm, all nodes that do not advertise participation for the CA Flex-Algorithm, as described in Section 3, MUST be pruned from the topology.

7. IANA Considerations

This document updates the ISIS "Sub-TLVs for TLV 242" registry as follows:

       +-------+--------------------------------+---------------------------+
       | Value |      TLV Name                  | Reference                 |
       +-------+--------------------------------+---------------------------+
       | TBD   |       CA Algorithm Sub-TLV     | This Document Section 3.1 |
       +-------+----------------------+-------------------------------------+
Figure 3: ISIS CA Algorithm Sub-TLV

This document updates the OSPFv3 Router Information (RI) TLVs registry as follows:

       +-------+--------------------------------+---------------------------+
       | Value |      TLV Name                  | Reference                 |
       +-------+--------------------------------+---------------------------+
       | TBD   |      CA Algorithm Sub-TLV      | This Document Section 3.2 |
       +-------+--------------------------------+---------------------------+
Figure 4: OSPFv3 CA Algorithm TLV

This document updates the ISIS Locator Flags registry as follows:

           Bit                #   Name
           ------------------   ------------------------------
           TBD(suggest bit 1)     CA Flex-Algorithm Flag (C-flag)
Figure 5: CA Flex-Algorithm Flag

This document updates the OSPFv3 Locator Flags registry as follows:

           Bit                #   Name
           ------------------   ------------------------------
           TBD(suggest bit 2)     CA Flex-Algorithm Flag (C-flag)
Figure 6: CA Flex-Algorithm Flag

This document also updates the ISIS and OSPFv3 SRv6 END.X and LAN END.X SID TLV Flags registry as follows:

           Bit                #   Name
           ------------------   ------------------------------
           TBD(suggest bit 4)     CA Flex-Algorithm Flag (C-flag)
Figure 7: END.X CA Flex-Algorithm Flag

8. References

8.1. Normative References

[I-D.ietf-6man-enhanced-vpn-vtn-id]
Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra, "Carrying Virtual Transport Network (VTN) Identifier in IPv6 Extension Header", Work in Progress, Internet-Draft, draft-ietf-6man-enhanced-vpn-vtn-id-00, , <https://www.ietf.org/archive/id/draft-ietf-6man-enhanced-vpn-vtn-id-00.txt>.
[I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", Work in Progress, Internet-Draft, draft-ietf-lsr-flex-algo-20, , <https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-20.txt>.
[I-D.ietf-lsr-isis-srv6-extensions]
Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and Z. Hu, "IS-IS Extensions to Support Segment Routing over IPv6 Dataplane", Work in Progress, Internet-Draft, draft-ietf-lsr-isis-srv6-extensions-18, , <https://www.ietf.org/archive/id/draft-ietf-lsr-isis-srv6-extensions-18.txt>.
[I-D.ietf-lsr-ospfv3-srv6-extensions]
Li, Z., Hu, Z., Talaulikar, K., and P. Psenak, "OSPFv3 Extensions for SRv6", Work in Progress, Internet-Draft, draft-ietf-lsr-ospfv3-srv6-extensions-05, , <https://www.ietf.org/archive/id/draft-ietf-lsr-ospfv3-srv6-extensions-05.txt>.
[I-D.li-6man-topology-id]
Li, Z., Hu, Z., and J. Dong, "Topology Identifier in IPv6 Extension Header", Work in Progress, Internet-Draft, draft-li-6man-topology-id-00, , <https://www.ietf.org/archive/id/draft-li-6man-topology-id-00.txt>.
[RFC7770]
Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, , <https://www.rfc-editor.org/info/rfc7770>.
[RFC7981]
Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, , <https://www.rfc-editor.org/info/rfc7981>.

8.2. Informative References

[I-D.ietf-lsr-ip-flexalgo]
Britto, W., Hegde, S., Kaneriya, P., Shetty, R., Bonica, R., and P. Psenak, "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks", Work in Progress, Internet-Draft, draft-ietf-lsr-ip-flexalgo-06, , <https://www.ietf.org/archive/id/draft-ietf-lsr-ip-flexalgo-06.txt>.
[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, , <https://www.rfc-editor.org/info/rfc8402>.
[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, , <https://www.rfc-editor.org/info/rfc8986>.

Authors' Addresses

Zhibo Hu
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing
100095
China
Guoqi Xu
Huawei
Huawei Bld., No. 156 Beiqing Rd.
Beijing
100095
China
Jie Dong
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing
100095
China