China Telecom

Beiqijia Town, Changping District Beijing 102209 China wangaj3@chinatelecom.cn

and define Multi-Topology (MT) routing for IS-IS and OSPF, respectively. When a topology-specific path crosses an AS boundary, a topology in one AS may need to be connected to a topology identified by a different MT-ID in the adjacent AS. Existing inter-AS Traffic Engineering extensions do not advertise this relationship. This document defines extensions to IS-IS and OSPF to advertise the binding between local and remote MT-IDs associated with an inter-AS link. 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 when, and only when, they appear in all capitals, as shown here.

defines Multi-Topology (MT) routing for IS-IS. RFC defines MT routing for OSPF. These mechanisms allow multiple logical topologies to be maintained within an IGP. An inter-AS path may traverse different MTs in different ASes. The MT-ID used in one AS does not need to be the same as the MT-ID used for the corresponding topology in an adjacent AS. For example:

MT-ID 10 in AS 65001 may be connected to MT-ID 20 in AS 65002 over the inter-AS link. The corresponding MT Binding is:

MT-ID 20]]>

defines IS-IS extensions for advertising inter-AS Traffic Engineering (TE) links. defines corresponding extensions for OSPF. These mechanisms advertise inter-AS link information and associated TE attributes, but do not identify the MTs connected by an inter-AS link. This document defines extensions to and to advertise this information. The MT Binding is configured on an ASBR and advertised into the local IGP. This document does not define a mechanism for exchanging MT Binding information across an inter-AS link.

This document uses the terminology defined in RFC 4915, RFC 5120, RFC 5392, and RFC 9346. Local MT-ID: The MT-ID of a topology in the AS originating the inter-AS link advertisement. Remote MT-ID: The MT-ID of the topology in the adjacent AS to which the local topology is connected over the inter-AS link. Inter-AS MT Binding: An association between a Local MT-ID and a Remote MT-ID on an inter-AS link..

An Inter-AS MT Binding associates a local MT with an inter-AS link and, when specified, identifies the corresponding MT in the adjacent AS. <Local MT-ID, Remote MT-ID> For example: <10, 20> indicates that local MT-ID 10 is connected to remote MT-ID 20 over the inter-AS link. A single inter-AS link may support multiple MT Bindings. For example:

The corresponding bindings are: <10, 20> <11, 21> Each MT Binding is advertised independently. The binding applies only to the inter-AS link with which it is advertised. The Local MT-ID and Remote MT-ID are configured on the advertising ASBR. MT-ID values are independently assigned and managed within each AS. A receiver associates an advertised MT Binding with the inter-AS link carrying the binding. A binding <X,Y> indicates that the inter-AS link connects local MT X to remote MT Y. When a configured MT Binding is added, changed, or removed, the ASBR MUST update the corresponding IGP advertisement.

defines the Inter-AS Reachability Information TLV (TLV 141) for advertising inter-AS TE links. This document defines a new Inter-AS MT Binding sub-TLV of TLV 141. Each instance of the sub-TLV advertises one MT Binding. The sub-TLV has the following format:.

Where: Type: TBD1 Length: 4 Local MT-ID: A 12-bit field identifying the local MT. Remote MT-ID: A 12-bit field identifying the corresponding MT in the adjacent AS. U: Remote MT-ID Unspecified. When set, the Remote MT-ID is unspecified. The Remote MT-ID field MUST be set to zero by the originator and MUST be ignored by the receiver. When clear, the Remote MT-ID field identifies the corresponding MT in the adjacent AS. R: Reserved. These bits MUST be set to zero when originated and MUST be ignored when received. If an inter-AS link supports multiple MT Bindings, multiple instances of the Inter-AS MT Binding sub-TLV MUST be included in the Inter-AS Reachability Information TLV.

The Inter-AS MT Binding sub-TLV MUST be carried in the Inter-AS Reachability Information TLV describing the inter-AS link to which the binding applies. A receiver that does not support this extension ignores the unknown sub-TLV according to normal IS-IS processing. The sub-TLV has the same flooding scope as the enclosing Inter-AS Reachability Information TLV.

defines the Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA for advertising inter-AS TE links in OSPFv2 and OSPFv3. Both LSAs contain a Link TLV describing an inter-AS link. This document defines a new Inter-AS MT Binding sub-TLV of the Link TLV. Each instance of the sub-TLV advertises one MT Binding. The sub-TLV has the following format:

Where: Type: TBD2 Length: 4 Local MT-ID: A 12-bit field identifying the local MT. Remote MT-ID: A 12-bit field identifying the corresponding MT in the adjacent AS. U: Remote MT-ID Unspecified. When set, the Remote MT-ID is unspecified. The Remote MT-ID field MUST be set to zero by the originator and MUST be ignored by the receiver. When clear, the Remote MT-ID field identifies the corresponding MT in the adjacent AS. R: Reserved. These bits MUST be set to zero when originated and MUST be ignored when received. If an inter-AS link supports multiple MT Bindings, multiple instances of the Inter-AS MT Binding sub-TLV MUST be included in the Inter-AS Reachability Information TLV. The sub-TLV has the same semantics for OSPFv2 and OSPFv3.

The Inter-AS MT Binding sub-TLV MUST be carried in the Link TLV describing the inter-AS link to which the binding applies. A receiver that does not support this extension ignores the unknown sub-TLV according to normal OSPF processing. The sub-TLV has the same flooding scope as the enclosing Inter-AS-TE LSA..

BGP-LS provides a mechanism to distribute link-state and Traffic Engineering information to external components, such as a Path Computation Element (PCE) or a controller. defines the Inter-AS Link NLRI for advertising inter-AS link information via BGP-LS. This document defines a new Inter-AS MT Binding TLV to advertise the MT Binding information associated with an Inter-AS Link NLRI. Each instance of the Inter-AS MT Binding TLV advertises one MT Binding. The TLV has the following format:

where: Type: TBD3. Length: 4 U (Remote MT-ID Unspecified): When set, the Remote MT-ID is unspecified. The Remote MT-ID field MUST be set to zero by the originator and MUST be ignored by the receiver. When clear, the Remote MT-ID field identifies the corresponding MT in the adjacent AS. Local MT-ID: A 12-bit field identifying the local MT. Remote MT-ID: A 12-bit field identifying the corresponding MT in the adjacent AS when the U bit is clear. R: Reserved. These bits MUST be set to zero when originated and MUST be ignored when received. The Inter-AS MT Binding TLV is carried in the BGP-LS Attribute associated with the Inter-AS Link NLRI defined in . When an Inter-AS MT Binding sub-TLV defined in or is advertised for an inter-AS link, a BGP-LS speaker supporting this extension MAY advertise the corresponding Inter-AS MT Binding TLV with the Inter-AS Link NLRI representing that link. The Local MT-ID, Remote MT-ID, and U bit MUST be copied from the corresponding IGP Inter-AS MT Binding sub-TLV. If multiple Inter-AS MT Bindings are associated with the same inter-AS link, a separate Inter-AS MT Binding TLV MUST be advertised for each binding.

MT Bindings are configured independently at each end of an inter-AS link. No MT Binding information is exchanged between the ASBRs by the mechanisms defined in this document. The configuration mechanism is implementation specific. An implementation SHOULD verify that the configured Local MT-ID is valid in the local IGP. The advertising ASBR is not required to verify the existence or configuration of the Remote MT-ID in the adjacent AS. Operators are responsible for coordinating the MT Binding configuration at the two ends of an inter-AS link. MT-ID 0 represents the default topology. A binding involving MT-ID 0 MAY therefore be advertised.

This document does not change the security mechanisms of IS-IS or OSPF. Incorrect MT Binding information may cause topology-specific path computation to select an unintended topology in an adjacent AS, resulting in incorrect forwarding or path selection. The authentication mechanisms applicable to the underlying IGP SHOULD be used to protect the advertisements. Operators SHOULD ensure that the configured MT Bindings are consistent with the intended inter-AS topology.

TBD

IANA is requested to allocate a new sub-TLV from the "Sub-TLVs for 22, 23, 25, 141, 222 and 223" registry:

IANA is requested to allocate a new sub-TLV from the applicable OSPF Traffic Engineering registry for use in the Link TLV of the Inter-AS-TE-v2 and Inter-AS-TE-v3 LSAs:

IANA is requested to allocate a new TLV from the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry: