| < draft-wang-lsr-stub-link-attributes-00.txt | draft-wang-lsr-stub-link-attributes-01.txt > | |||
|---|---|---|---|---|
| LSR Working Group A. Wang | LSR Working Group A. Wang | |||
| Internet-Draft China Telecom | Internet-Draft China Telecom | |||
| Intended status: Standards Track Z. Hu | Intended status: Standards Track Z. Hu | |||
| Expires: 1 February 2022 Huawei Technologies | Expires: March 26, 2022 Huawei Technologies | |||
| G. Mishra | G. Mishra | |||
| Verizon Inc. | Verizon Inc. | |||
| A. Lindem | ||||
| Cisco Systems | ||||
| J. Sun | J. Sun | |||
| ZTE Corporation | ZTE Corporation | |||
| 31 July 2021 | September 22, 2021 | |||
| Advertisement of Stub Link Attributes | Advertisement of Stub Link Attributes | |||
| draft-wang-lsr-stub-link-attributes-00 | draft-wang-lsr-stub-link-attributes-01 | |||
| Abstract | Abstract | |||
| This document describes the mechanism that can be used to | This document describes the mechanism that can be used to | |||
| differentiate the stub links from the normal interfaces within ISIS | differentiate the stub links from the normal interfaces within ISIS | |||
| or OSPF domain. | or OSPF domain. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| skipping to change at page 1, line 37 ¶ | skipping to change at page 1, line 39 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 1 February 2022. | This Internet-Draft will expire on March 26, 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2021 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
| license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
| and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
| extracted from this document must include Simplified BSD License text | to this document. Code Components extracted from this document must | |||
| as described in Section 4.e of the Trust Legal Provisions and are | include Simplified BSD License text as described in Section 4.e of | |||
| provided without warranty as described in the Simplified BSD License. | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Conventions used in this document . . . . . . . . . . . . . . 3 | 2. Conventions used in this document . . . . . . . . . . . . . . 3 | |||
| 3. Consideration for flagging passive interface . . . . . . . . 3 | 3. Consideration for Identifying Stub Link . . . . . . . . . . . 3 | |||
| 4. Passive Interface Attribute . . . . . . . . . . . . . . . . . 4 | 4. Protocol Extension for Stub Link Attributes . . . . . . . . . 3 | |||
| 4.1. OSPFv2 Extended Stub-Link TLV . . . . . . . . . . . . . . 4 | 4.1. OSPF Stub-Link TLV . . . . . . . . . . . . . . . . . . . 4 | |||
| 4.2. OSPFv3 Router-Stub-Link TLV . . . . . . . . . . . . . . . 5 | 4.2. ISIS Stub-link Sub-TLV . . . . . . . . . . . . . . . . . 5 | |||
| 4.3. ISIS Stub-link TLV . . . . . . . . . . . . . . . . . . . 6 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | |||
| 4.4. Stub-Link Prefix Sub-TLV . . . . . . . . . . . . . . . . 7 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 8.2. Informative References . . . . . . . . . . . . . . . . . 7 | |||
| 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 8.2. Informative References . . . . . . . . . . . . . . . . . 10 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | ||||
| 1. Introduction | 1. Introduction | |||
| Stub links are used commonly within an operators enterprise or | Stub links are used commonly within an operators enterprise or | |||
| service provider networks. One of the most common use cases for stub | service provider networks. One of the most common use cases for stub | |||
| links is in a data center Layer 2 and Layer 3 Top of Rack(TOR) switch | links is in a data center Layer 2 and Layer 3 Top of Rack(TOR) switch | |||
| where the inter connected links between the TOR switches and uplinks | where the inter connected links between the TOR switches and uplinks | |||
| to the core switch are only a few links and a majority of the links | to the core switch are only a few links and a majority of the links | |||
| are Layer 3 VLAN switched virtual interface trunked between the TOR | are Layer 3 VLAN switched virtual interface trunked between the TOR | |||
| switches serving Layer 2 broadcast domains. In this scenario all the | switches serving Layer 2 broadcast domains. In this scenario all the | |||
| VLANs are made as stub links as it is recommended to limit the number | VLANs are made as stub links as it is recommended to limit the number | |||
| of network LSAs between routers and switches to avoid unnecessary | of network LSAs between routers and switches to avoid unnecessary | |||
| hello processing overhead. | hello processing overhead. | |||
| Another common use case is an inter-as routing scenario where the | Another common use case is an inter-AS routing scenario where the | |||
| same routing protocol but different IGP instance is running between | same routing protocol but different IGP instance is running between | |||
| the adjacent BGP domains. Using stub link on the inter-as | the adjacent BGP domains. Using stub link on the inter-AS | |||
| connections can ensure that prefixes contained within a domain are | connections can ensure that prefixes contained within a domain are | |||
| only reachable within the domain itself and not allow the link state | only reachable within the domain itself and not allow the link state | |||
| database to be merged between domain which could result in | database to be merged between domain which could result in | |||
| undesirable consequences. | undesirable consequences. | |||
| For operator which runs different IGP domains that interconnect with | For operator which runs different IGP domains that interconnect with | |||
| each other via the stub links, there is desire to obtain the inter-as | each other via the stub links, there is desire to obtain the inter-AS | |||
| topology information as described in | topology information as described in | |||
| [I-D.ietf-idr-bgpls-inter-as-topology-ext]. If the router that runs | [I-D.ietf-idr-bgpls-inter-as-topology-ext]. If the router that runs | |||
| BGP-LS within one IGP domain can distinguish stub links from other | BGP-LS within one IGP domain can distinguish stub links from other | |||
| normal interfaces, it is then easy for the router to report these | normal interfaces, it is then easy for the router to report these | |||
| stub links using BGP-LS to a centralized PCE controller. | stub links using BGP-LS to a centralized PCE controller. | |||
| Draft [I-D.dunbar-lsr-5g-edge-compute-ospf-ext] describes the case | Draft [I-D.dunbar-lsr-5g-edge-compute] describes the case that edge | |||
| that edge compute server attach the network and needs to flood some | compute server attach the network and needs to flood some performance | |||
| performance index information to the network to facilitate the | index information to the network to facilitate the network select the | |||
| network select the optimized application resource. The edge compute | optimized application resource. The edge compute server will also | |||
| server will also not run IGP protocol. | not run IGP protocol. | |||
| And, stub links are normally the boundary of one IGP domain, knowing | And, stub links are normally the boundary of one IGP domain, knowing | |||
| them can facilitate the operators to apply various policies on such | them can facilitate the operators to apply various policies on such | |||
| interfaces, for example, to secure their networks, or filtering the | interfaces, for example, to secure their networks, or filtering the | |||
| incoming traffic with scrutiny. | incoming traffic with scrutiny. | |||
| But OSPF and ISIS have no position to flag such stub links and their | But OSPF and ISIS have no position to identify such stub links and | |||
| associated attributes now. | their associated attributes now. | |||
| This document defines the protocol extension for OSPF and ISIS to | This document defines the protocol extension for OSPFv2/v3 and ISIS | |||
| indicate the stub links and their associated attributes. | to indicate the stub links and their associated attributes. | |||
| 2. Conventions used in this document | 2. Conventions used in this document | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in [RFC2119] . | document are to be interpreted as described in [RFC2119] . | |||
| 3. Consideration for flagging passive interface | 3. Consideration for Identifying Stub Link | |||
| ISIS[RFC5029] defines the Link-Attributes Sub-TLV to carry the link | ||||
| attribute information, but this Sub-TLV can only be carried within | ||||
| the TLV 22, which is used to described the attached neighbor. For | ||||
| stub link, there is no ISIS neighbor, then it is not appropriate to | ||||
| use this Sub-TLV to indicate the attribute of such link. | ||||
| OSPFv2[RFC2328] defines link type field within Router LSA, the type 3 | OSPF[RFC5392] defines the Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA | |||
| for connections to a stub network can be used to identified the stub | to carry the TE information about inter-AS links. These LSAs can be | |||
| link. But in OSPFv3[RFC5340], type 3 within the Router-LSA has been | used to transfer the information about the stub link which is located | |||
| reserved. The information that associated with stub network has been | at the boundary of one AS. This document defines the Stub-Link TLV | |||
| put in the Intra-Area-Prefix-LSAs. | within these LSAs to identify the stub link and transfer the | |||
| associated attributes then. | ||||
| It is necessary to define one general solution for ISIS and OSPF to | ISIS[RFC5316] defines the Inter-AS Reachability TLV to carry the TE | |||
| flag the stub link and transfer the associated attributes then. | information about inter-AS links. This TLV can be used to transfer | |||
| the information about the stub link which is located at the boundary | ||||
| of one AS. This document defines the Stub-Link sub-TLV within this | ||||
| TLV to identify the stub link and transfer the associated attributes. | ||||
| 4. Passive Interface Attribute | 4. Protocol Extension for Stub Link Attributes | |||
| The following sections define the protocol extension to indicate the | The following sections define the protocol extension to indicate the | |||
| stub link and its associated attributes in OSPFv2/v3 and ISIS. | stub link and its associated attributes in OSPFv2/v3 and ISIS. | |||
| 4.1. OSPFv2 Extended Stub-Link TLV | 4.1. OSPF Stub-Link TLV | |||
| [RFC7684] defines the OSPFv2 Extended Link Opaque LSA to contain the | This document defines the OSPF Stub-Link TLV to describe stub link of | |||
| additional link attribute TLV. Currently, only OSPFv2 Extended Link | a single router. This Stub-Link TLV is only applicable to the Inter- | |||
| TLV is defined to contain the link related sub-TLV. Because stub | AS-TE-v2 LSA and Inter-AS-TE-v3 LSA. Inclusion in other LSA MUST be | |||
| link is not the normal link that participate in the OSPFv2 process, | ignored. | |||
| we select to define one new top TLV within the OSPFv2 Extended Link | ||||
| Opaque LSA to contain the stub link related attribute information. | ||||
| The OSPFv2 Extended Stub-Link TLV has the following format: | The OSPF Stub-Link TLV which is under the IANA codepoint "Top Level | |||
| Types in TE LSAs" has the following format: | ||||
| 0 1 2 3 | 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 | 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(Stub-Link) | Length | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Link Type | Reserved | Metric | | | Type(Stub-Link) | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Link ID | | | Link Type | Prefix Length | Reserved | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Link Data | | | Link Prefix(variable) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Sub-TLVs (variable) | | | Sub-TLVs (variable) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 1: OSPFv2 Extended Stub-Link TLV | Figure 1: OSPF Stub-Link TLV | |||
| Type: The TLV type. The value is 2(TBD) for this stub-link type | Type: The TLV type. The value is 7(TBD) for OSPF Stub-Link | |||
| Length: Variable, dependent on sub-TLVs | Length: Variable, dependent on sub-TLVs | |||
| Link Type: Define the type of the stub-link. This document defines | Link Type: Define the type of the stub-link. This document defines | |||
| the followings type: | the followings type: | |||
| * 0: Reserved | o 0: Reserved | |||
| * 1: AS boundary link | o 1: AS boundary link | |||
| * 2: Loopback link | o 2: Loopback link | |||
| * 3: Vlan interface link | o 3: Vlan interface link | |||
| * 4-255: For future extension | o 4-255: For future extension | |||
| Metric: Link metric used for inter-AS traffic engineering. | ||||
| Link ID: Link ID is defined in Section A.4.2 of [RFC2328] | Prefix Length: The length of the interface address, in octet. | |||
| Link Data: Link Data is defined in Section A.4.2 of [RFC2328] | Link Prefix: The prefix of the stub-link. It's length is determined | |||
| by the field "Prefix Length". | ||||
| Sub-TLVs: Existing sub-TLV that defined within "OSPFv2 Extended Link | Sub-TLVs: Existing sub-TLV that defined within "Open Shortest Path | |||
| TLV Sub-TLV" can be included if necessary, the definition of new sub- | First (OSPF) Traffic Engineering TLVs" for TE Link TLV(Value 2) can | |||
| TLV can refer to Section 4.4 | be included if necessary. | |||
| If this TLV is advertised multiple times in the same OSPFv2 Extended | If this TLV is advertised multiple times in the same Inter-AS-TE-v2/ | |||
| Link Opaque LSA, only the first instance of the TLV is used by | v3 LSA, only the first instance of the TLV is used by receiving | |||
| receiving OSPFv2 routers. This situation SHOULD be logged as an | OSPFv2/v3 routers. This situation SHOULD be logged as an error. | |||
| error. | ||||
| If this TLV is advertised multiple times for the same link in | If this TLV is advertised multiple times for the same link in | |||
| different OSPFv2 Extended Link Opaque LSAs originated by the same | different Inter-AS-TE-v2/v3 LSA originated by the same OSPFrouter, | |||
| OSPFv2 router, the OSPFv2 Extended Stub-Link TLV in the OSPFv2 | the OSPFStub-Link TLV in these LSAs with the smallest Opaque ID is | |||
| Extended Link Opaque LSA with the smallest Opaque ID is used by | used by receiving OSPFrouters. This situation may be logged as a | |||
| receiving OSPFv2 routers. This situation may be logged as a warning. | warning. | |||
| It is RECOMMENDED that OSPFv2 routers advertising OSPFv2 Extended | It is RECOMMENDED that OSPF routers advertising OSPF Stub-Link TLVs | |||
| Stub-Link TLVs in different OSPFv2 Extended Link Opaque LSAs re- | in different OSPF Inter-AS-TE v2/v3 LSAs re-originate these LSAs in | |||
| originate these LSAs in ascending order of Opaque ID to minimize the | ascending order of Opaque ID to minimize the disruption. | |||
| disruption. | ||||
| This document creates a registry for Stub-Link attribute in | This document creates a registry for Stub-Link attributes in | |||
| Section 6. | Section 6. | |||
| 4.2. OSPFv3 Router-Stub-Link TLV | 4.2. ISIS Stub-link Sub-TLV | |||
| [RFC8362] extend the LSA format by encoding the existing OSPFv3 LSA | ||||
| [RFC5340] in TLV tuples and allowing advertisement of additional | ||||
| information with additional TLV. | ||||
| This document defines the Router-Stub-Link TLV to describes stub link | ||||
| of a single router. The Router-Stub-Link TLV is only applicable to | ||||
| the E-Router-LSA. Inclusion in other Extended LSA MUST be ignored. | ||||
| 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(Router-Stub-Link) | Length | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Link Type | Reserved | Metric | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Interface ID | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Sub-TLVs(Variable) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Figure 2: OSPFv3 Router-Stub-Link TLV | ||||
| Type: OSPFv3 Extended-LSA TLV Type. Value is 10(TBD) for Router- | ||||
| Stub-Link TLV. | ||||
| Length: Variable, dependent on sub-TLVs | ||||
| Link Type: Define the type of the stub-link. This document defines | ||||
| the followings type: | ||||
| * 0: Reserved | ||||
| * 1: AS boundary link | ||||
| * 2: Loopback link | ||||
| * 3: Vlan interface link | ||||
| * 4-255: For future extension | ||||
| Metric: Link metric used for inter-AS traffic engineering. | ||||
| Interface ID: 32-bit number uniquely identifying this interface among | ||||
| the collection of this router's interfaces. For example, in some | ||||
| implementations it may be possible to use the MIB-II IfIndex | ||||
| [RFC2863]. | ||||
| Sub-TLVs: Existing sub-TLV that defined within "OSPFv3 Extended-LSA | ||||
| Sub-TLV" can be included if necessary. The definition of new sub-TLV | ||||
| can refer to Section 4.4. | ||||
| 4.3. ISIS Stub-link TLV | This document defines the ISIS Stub-Link sub-TLV to describes stub | |||
| link of a single router. This Stub-Link sub-TLV is only applicable | ||||
| to the Inter-AS Reachability TLV. Inclusion in other TLV MUST be | ||||
| ignored. | ||||
| This document defines one new top TLV to contain the stub link | The ISIS Stub-Link sub-TLV which is under the IANA codepoint "Sub- | |||
| attributes, which is shown in Figure 4: | TLVs for TLVs 22, 23, 25, 141, 222, and 223" has the following | |||
| format: | ||||
| 0 1 2 3 | 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 | 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(Stub-Link) | Length | | | Type(Stub-Link) | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Link Type | Reserved | Metric | | | Link Type | Prefix Length | Reserved | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Interface ID | | | Link Prefix(variable) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Sub-TLVs(Variable) | | | Sub-TLVs(Variable) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 3: ISIS Stub-Link TLV | Figure 2: ISIS Stub-Link Sub-TLV | |||
| Type: ISIS TLV Codepoint. Value is 28(TBD) for stub-link TLV. | Type: ISIS sub-TLV codepoint. Value is 45(TBD) for stub-link TLV. | |||
| Length: Variable, dependent on sub-TLVs | Length: Variable, dependent on sub-TLVs | |||
| Link Type: Define the type of the stub-link. This document defines | Link Type: Define the type of the stub-link. This document defines | |||
| the followings type: | the followings type: | |||
| * 0: Reserved | o 0: Reserved | |||
| * 1: AS boundary link | ||||
| * 2: Loopback link | ||||
| * 3: Vlan interface link | ||||
| * 4-255: For future extension | ||||
| Metric: Link metric used for inter-AS traffic engineering. | ||||
| Interface ID: 32-bit number uniquely identifying this interface among | ||||
| the collection of this router's interfaces. For example, in some | ||||
| implementations it may be possible to use the MIB-II IfIndex | ||||
| [RFC2863]. | ||||
| Sub-TLVs: Existing sub-TLV that defined within "Sub-TLVs for TLVs 22, | ||||
| 23, 25, 141, 222, and 223" can be included if necessary. The | ||||
| definition of new sub-TLV can refer to Section 4.4. | ||||
| 4.4. Stub-Link Prefix Sub-TLV | ||||
| This document defines one new sub-TLV that can be contained within | o 1: AS boundary link | |||
| the OSPFv2 Extended Stub-Link TLV , OSPFv3 Router-Stub-Link TLV or | ||||
| ISIS Stub-Link TLV, to describe the prefix information associated | ||||
| with the stub link. | ||||
| The format of the sub-TLV is the followings: | o 2: Loopback link | |||
| 0 1 2 3 | o 3: Vlan interface link | |||
| 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 | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | IPv4 Prefix or IPv6 Prefix Subobject | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Figure 4: Stub-Link Prefix Sub-TLV | ||||
| Type: The TLV type. The value is 01(TBD) for this Stub-Link Prefix | o 4-255: For future extension | |||
| type | ||||
| Length: Variable, dependent on associated subobjects | Prefix Length: The length of the interface address, in octet. | |||
| Subobject: IPv4 prefix subobject or IPv6 prefix subobject, as that | Link Prefix: The prefix of the stub-link. It's length is determined | |||
| defined in [RFC3209] | by the field "Prefix Length". | |||
| If the stub link has multiple address, then multiple subobjects will | Sub-TLVs: Existing sub-TLVs that defined within "Sub-TLVs for TLVs | |||
| be included within this sub-TLV. | 22, 23, 25, 141, 222, and 223" can be included if necessary. | |||
| 5. Security Considerations | 5. Security Considerations | |||
| Security concerns for ISIS are addressed in [RFC5304] and[RFC5310] | Security concerns for ISIS are addressed in [RFC5304] and[RFC5310] | |||
| Security concern for OSPFv3 is addressed in [RFC4552] | Security concern for OSPFv3 is addressed in [RFC4552] | |||
| Advertisement of the additional information defined in this document | Advertisement of the additional information defined in this document | |||
| introduces no new security concerns. | introduces no new security concerns. | |||
| 6. IANA Considerations | 6. IANA Considerations | |||
| IANA is requested to the allocation in following registries: | IANA is requested to the allocation in following registries: | |||
| +=========================+===========+======================+ | +===========================+======+===========================+ | |||
| | Registry | Type | Meaning | | | Registry | Type | Meaning | | |||
| +=========================+===========+======================+ | +===========================+======+===========================+ | |||
| |OSPFv2 Extended Link | 2 |Stub-Link TLV | | |Top Level Types in TE LSAs | 7 |OSPF Stub-Link TLV | | |||
| |Opaque LSA TLV | | | | +---------------------------+------+---------------------------+ | |||
| +-------------------------+-----------+----------------------+ | |Sub-TLVs for TLVs 22, 23, | | | | |||
| |OSPFv3 Extended-LSA TLV | 10 |Router-Stub-Link TLV | | | 25, 141, 222, and 223 | 45 |IS-IS Stub-Link sub-TLV | | |||
| +-------------------------+-----------+----------------------+ | +---------------------------+------+---------------------------+ | |||
| |IS-IS TLV Codepoint | 28 |Stub-Link TLV | | Figure 3: IANA Allocation for newly defined TLVs | |||
| +-------------------------+-----------+----------------------+ | ||||
| Figure 5: Newly defined TLV in existing IETF registry | ||||
| IANA is requested to allocate one new registry that can be referred | ||||
| by OSPFv2, OSPFv3 and ISIS respectively. | ||||
| +=========================+==================================+ | ||||
| | New Registry | Meaning | | ||||
| +=========================+==================================+ | ||||
| |Stub-Link Attribute | Attributes for stub-link | | ||||
| +-------------------------+----------------------------------+ | ||||
| Figure 6: Newly defined Registry for stub-link attributes | ||||
| One new sub-TLV is defined in this document under this registry | ||||
| codepoint: | ||||
| +=========================+===========+===============================+ | ||||
| | Registry | Type | Meaning | | ||||
| +=========================+===========+===============================+ | ||||
| |Stub-Link Attribute | 0 | Reserved | ||||
| +=========================+===========+===============================+ | ||||
| | | 1 |Stub-Link Prefix sub-TLV | | ||||
| +-------------------------+-----------+-------------------------------+ | ||||
| | | 2-65535 |Reserved | | ||||
| +-------------------------+-----------+-------------------------------+ | ||||
| Figure 7: Stub-Link Prefix Sub-TLV | ||||
| 7. Acknowledgement | 7. Acknowledgement | |||
| Thanks Shunwan Zhang, Tony Li, Les Ginsberg, Acee Lindem, Dhruv | Thanks Shunwan Zhang, Tony Li, Les Ginsberg, Acee Lindem, Dhruv | |||
| Dhody, Jeff Tantsura and Robert Raszuk for their suggestions and | Dhody, Jeff Tantsura and Robert Raszuk for their suggestions and | |||
| comments on this idea. | comments on this idea. | |||
| 8. References | 8. References | |||
| 8.1. Normative References | 8.1. Normative References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, | ||||
| DOI 10.17487/RFC2328, April 1998, | ||||
| <https://www.rfc-editor.org/info/rfc2328>. | ||||
| [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group | ||||
| MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, | ||||
| <https://www.rfc-editor.org/info/rfc2863>. | ||||
| [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | ||||
| and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP | ||||
| Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, | ||||
| <https://www.rfc-editor.org/info/rfc3209>. | ||||
| [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality | [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality | |||
| for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, | for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, | |||
| <https://www.rfc-editor.org/info/rfc4552>. | <https://www.rfc-editor.org/info/rfc4552>. | |||
| [RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link | ||||
| Attribute Sub-TLV", RFC 5029, DOI 10.17487/RFC5029, | ||||
| September 2007, <https://www.rfc-editor.org/info/rfc5029>. | ||||
| [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic | [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic | |||
| Authentication", RFC 5304, DOI 10.17487/RFC5304, October | Authentication", RFC 5304, DOI 10.17487/RFC5304, October | |||
| 2008, <https://www.rfc-editor.org/info/rfc5304>. | 2008, <https://www.rfc-editor.org/info/rfc5304>. | |||
| [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., | [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., | |||
| and M. Fanto, "IS-IS Generic Cryptographic | and M. Fanto, "IS-IS Generic Cryptographic | |||
| Authentication", RFC 5310, DOI 10.17487/RFC5310, February | Authentication", RFC 5310, DOI 10.17487/RFC5310, February | |||
| 2009, <https://www.rfc-editor.org/info/rfc5310>. | 2009, <https://www.rfc-editor.org/info/rfc5310>. | |||
| [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF | [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in | |||
| for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, | Support of Inter-Autonomous System (AS) MPLS and GMPLS | |||
| <https://www.rfc-editor.org/info/rfc5340>. | Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, | |||
| December 2008, <https://www.rfc-editor.org/info/rfc5316>. | ||||
| [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>. | ||||
| [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>. | ||||
| [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and | [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in | |||
| F. Baker, "OSPFv3 Link State Advertisement (LSA) | Support of Inter-Autonomous System (AS) MPLS and GMPLS | |||
| Extensibility", RFC 8362, DOI 10.17487/RFC8362, April | Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, | |||
| 2018, <https://www.rfc-editor.org/info/rfc8362>. | January 2009, <https://www.rfc-editor.org/info/rfc5392>. | |||
| 8.2. Informative References | 8.2. Informative References | |||
| [I-D.dunbar-lsr-5g-edge-compute-ospf-ext] | [I-D.dunbar-lsr-5g-edge-compute] | |||
| Dunbar, L., Chen, H., and A. Wang, "OSPF extension for 5G | Dunbar, L., Chen, H., and C. Telecom, "IS-IS & OSPF | |||
| Edge Computing Service", Work in Progress, Internet-Draft, | extension for 5G Edge Computing Service", draft-dunbar- | |||
| draft-dunbar-lsr-5g-edge-compute-ospf-ext-04, 10 March | lsr-5g-edge-compute-00 (work in progress), July 2021. | |||
| 2021, <https://www.ietf.org/archive/id/draft-dunbar-lsr- | ||||
| 5g-edge-compute-ospf-ext-04.txt>. | ||||
| [I-D.ietf-idr-bgpls-inter-as-topology-ext] | [I-D.ietf-idr-bgpls-inter-as-topology-ext] | |||
| Wang, A., Chen, H., Talaulikar, K., and S. Zhuang, "BGP-LS | Wang, A., Chen, H., Talaulikar, K., and S. Zhuang, "BGP-LS | |||
| Extension for Inter-AS Topology Retrieval", Work in | Extension for Inter-AS Topology Retrieval", draft-ietf- | |||
| Progress, Internet-Draft, draft-ietf-idr-bgpls-inter-as- | idr-bgpls-inter-as-topology-ext-09 (work in progress), | |||
| topology-ext-09, 28 September 2020, | September 2020. | |||
| <https://www.ietf.org/archive/id/draft-ietf-idr-bgpls- | ||||
| inter-as-topology-ext-09.txt>. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Aijun Wang | Aijun Wang | |||
| China Telecom | China Telecom | |||
| Beiqijia Town, Changping District | Beiqijia Town, Changping District | |||
| Beijing | Beijing 102209 | |||
| 102209 | ||||
| China | China | |||
| Email: wangaj3@chinatelecom.cn | Email: wangaj3@chinatelecom.cn | |||
| Zhibo Hu | Zhibo Hu | |||
| Huawei Technologies | Huawei Technologies | |||
| Huawei Bld., No.156 Beiqing Rd. | Huawei Bld., No.156 Beiqing Rd. | |||
| Beijing | Beijing 100095 | |||
| 100095 | ||||
| China | China | |||
| Email: huzhibo@huawei.com | Email: huzhibo@huawei.com | |||
| Gyan S. Mishra | Gyan S. Mishra | |||
| Verizon Inc. | Verizon Inc. | |||
| 13101 Columbia Pike | 13101 Columbia Pike | |||
| Silver Spring, MD 20904 | Silver Spring MD 20904 | |||
| United States of America | United States of America | |||
| Email: gyan.s.mishra@verizon.com | Email: gyan.s.mishra@verizon.com | |||
| Acee Lindem | ||||
| Cisco Systems | ||||
| No. 301 Midenhall Way | ||||
| Cary NC 27513 | ||||
| United States of America | ||||
| Email: acee@cisco.com | ||||
| Jinsong Sun | Jinsong Sun | |||
| ZTE Corporation | ZTE Corporation | |||
| No. 68, Ziijnhua Road | No. 68, Ziijnhua Road | |||
| Nan Jing | Nan Jing 210012 | |||
| 210012 | ||||
| China | China | |||
| Email: sun.jinsong@zte.com.cn | Email: sun.jinsong@zte.com.cn | |||
| End of changes. 66 change blocks. | ||||
| 281 lines changed or deleted | 147 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||