BGP Extensions for the Mobile User Plane (MUP) SAFI

This draft defines a new BGP SAFI known as a BGP-MUP SAFI. The value of this SAFI is to be assigned by IANA from the Subsequent Address Family Identifiers (SAFI) registry. This document also defines a new BGP NLRI known as the BGP-MUP NLRI. The following is the format of the BGP-MUP NLRI:

The Architecture Type field defines the encoding of the rest of BGP-MUP NLRI for a given Mobile User Plane architecture. This draft defines the following architecture type for BGP-MUP NLRI:

The Route Type field defines the encoding of the rest of BGP-MUP NLRI (Route Type specific BGP-MUP NLRI) for a given architecture type. The Length field indicates the length in octets of the Route Type specific field of the BGP-MUP NLRI. This document defines the following Route Types for BGP-MUP NLRI.

These Route Types are applicable for the 3gpp-5G architecture type as per . Other new architectures can share them if it is applicable as well. The BGP-MUP NLRI is carried in BGP using BGP Multiprotocol Extensions with an Address Family Identifier (AFI) of 1 or 2 and a Subsequent AFI (SAFI) of BGP-MUP. The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the BGP-MUP NLRI (encoded as specified above). The value of the AFI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute that carries the BGP-MUP NLRI determines whether the addresses carried in the routes are IPv4 or IPv6 addresses (AFI 1 indicates IPv4 addresses, AFI 2 indicates IPv6 addresses). In order for two BGP speakers to exchange BGP-MUP NLRIs, they must use a BGP Capabilities Advertisement to ensure that they both are capable of properly processing such an NLRI. This is done as specified in , by using capability code 1 (multiprotocol BGP) with an AFI of 1 or 2 and an SAFI of BGP-MUP. This document defines 4 Route Types for 3gpp-5G architecture type. Any other Route Types MUST be silently ignored upon a receipt if a BGP speaker supports only 3gpp-5G architecture type. An implementation MAY log an error when such Route Types are ignored. An implementation MAY considered retrieving any discarded Route Types by simply resetting the session or issuing a Route-REFRESH message if the Route Refresh Capability is successfully negotiated. The following sections describes the format of the Route Type specific BGP-MUP NLRI for various Route Types defined in this document.

A BGP Interwork Segment Discovery route Type specific BGP-MUP NLRI consist of the following:

The Interwork Segment Discovery route Type NLRI consist of RD which is encoded as described in . It also has an prefix associated with Interwork segment connected locally. For the purpose of BGP route key processing, only the RD, Prefix Length and Prefix are considered to be part of the prefix in the NLRI. In 3GPP 5G specific case, a prefix used for a N3 interface of the gNodeB connected locally MAY be used as this prefix. The prefix length of one octet indicating length of the prefix. If the AFI is IPv4, then the maximum value of the Prefix Length is 32 bits otherwise it is considered as a malformed NLRI. If the AFI is IPv6, then the maximum value of of the Prefix length is 128 bits otherwise it is considered as a malformed NLRI. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.

A BGP Direct Segment Discovery route Type specific BGP-MUP NLRI consist of the following:

The Direct Segment Discovery route Type NLRI consist of RD which is encoded as described in . It also has an Address of originating BGP speaker. For the purpose of BGP route key processing, only the RD and Address are considered to be part of the prefix in the NLRI. If the AFI is IPv4 then the address length is 4 octets otherwise it is considered as a malformed NLRI. If the AFI is IPv6 then the address length is 16 octets otherwise it is considered as a malformed NLRI. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.

A BGP Type 1 ST Route Type specific BGP-MUP NLRI consist of the following:

The Type 1 ST Route Type NLRI consist of RD which is encoded as described in . It also has Prefix length of one octet indicating length of the Prefix. For the purpose of BGP route key processing, only the RD, Prefix Length and Prefix are considered to be part of the prefix in the NLRI. In 3GPP 5G specific case, Prefix is the prefix allocated to a UE. If the AFI is IPv4, then the maximum value of the Prefix Length field is 32. If the AFI is IPv6, then the maximum value of the Prefix Length field is 128. Any other length field is considered a a malformed NLRI. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. The architecture specific encoding values will follow after the variable length Prefix.

A BGP 3gpp-5g Type 1 ST Route Type specific BGP-MUP NLRI consist of the following:

The TEID has a fixed length of 4 octets. The TEID value of 0 is considered as an invalid and a malformed TEID. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. The QFI has a fixed length of 1 octet. The Endpoint Address Length has a fixed length of 1 octet. Endpoint Address field contains of an IPv4 address, then the value of the Endpoint Address Length field is 32. If the Endpoint Address field contains of an IPv6 Address, then the value of the Endpoint Address Length field is 128. Any other value is considered as an invalid and a malformed Endpoint Address. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. The Source Address Length has a fixed length of 1 octet. Source Address Length is 0 bytes then the Source address is not carried within the NLRI. A BGP speaker MAY have a local configuration for using a Source address. The exact mechanism of local configuration is outside the scope of this document. Source Address field contains of an IPv4 address, then the value of the Source Address Length field is 32. If the Source Address field contains of an IPv6 Address, then the value of the Source Address Length field is 128. Any other value is considered as an invalid and a malformed Endpoint Address. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. Optional TLVs may follow after the Source Address field. To determine their presence, compute the number of remaining octets by subtracting, from the Length field in the MUP NLRI common header, the offset of the end of the Source Address measured from the start of the Route Type specific field. Based on this value: the mandatory fields exceed the declared Length; the NLRI is malformed; MUST be treated as Treat-as-withdraw. no TLVs are present. encoding is invalid (a valid TLV requires at minimum a Type byte and a Length byte); MUST be treated as Treat-as-withdraw. one or more TLVs are present. Parse TLVs one by one per ; unknown TLV types MUST be ignored for local processing and MUST be propagated unchanged when re-advertising the route to other BGP peers; any TLV parsing error MUST result in Treat-as-withdraw; TLVs are not part of the NLRI key for route processing. The NLRI architecture field MUST be encoded as shown above if a BGP speaker receives 3gpp-5g specific BGP Type 1 ST route. Otherwise the NLRI is considered as a malformed. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.

A BGP Type 2 ST Route Type specific BGP-MUP NLRI consist of the following:

The Type 2 ST Route Type NLRI consist of RD which is encoded as described in . It also has Endpoint length of one octet indicating length of the Endpoint Address and the Architecture specific Endpoint Identifier as per defines aggregation capability by the Type2 ST Route. If the AFI is IPv4 and the Endpoint Length is longer than 32 then the Architecture specific endpoint Identifier field exists with the IPv4 Endpoint Address. If the AFI is IPv6 and the Endpoint Length is longer than 128 then the Architecture specific endpoint Identifier field exists with then the IPv6 Endpoint Address. For the purpose of BGP route key processing, only the RD, Endpoint Address and Architecture specific Endpoint Identifier are considered to be part of the prefix in the NLRI. In 3GPP 5G specific case, the Endpoint Address is a N3 interface address of the UPF. If the AFI is IPv4, then the maximum Endpoint length is 64 otherwise it is considered as a malformed NLRI. If the AFI is IPv6, then the maximum Endpoint length is 160 otherwise it is considered as a malformed NLRI. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. The architecture specific encoding values will follow after the variable length Prefix.

A BGP 3gpp-5g Type 2 ST Route Type specific BGP-MUP NLRI consist of the following:

The maximum length of TEID is 4 octets. The TEID value of 0 is considered as an invalid and a malformed TEID. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. The Endpoint Length MUST NOT extend beyond the TEID field. The TEID length is zero or more bytes as determined by the Endpoint Length value. Optional TLVs may follow after the TEID. To determine their presence, compute the number of remaining octets by subtracting, from the Length field in the MUP NLRI common header, the offset of the end of TEID measured from the start of the Route Type specific field. Based on this value: the mandatory fields exceed the declared Length; the NLRI is malformed; MUST be treated as Treat-as-withdraw. no TLVs are present. encoding is invalid (a valid TLV requires at minimum a Type byte and a Length byte); MUST be treated as Treat-as-withdraw. one or more TLVs are present. Parse TLVs one by one per ; unknown TLV types MUST be ignored for local processing and MUST be propagated unchanged when re-advertising the route to other BGP peers; any TLV parsing error MUST result in Treat-as-withdraw; TLVs are not part of the NLRI key for route processing. The NLRI architecture field MUST be encoded as shown above if a BGP speaker receives 3gpp-5g specific BGP Type 2 ST route. Otherwise the NLRI is considered as a malformed. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.

All TLVs have the following format:

Both Type and Length fields are one byte long. The Length field indicates the length in octets of the Value field. Each TLV definition specifies which route types it is applicable to. A TLV received in a route type for which it is not applicable MUST be ignored. Currently 3 TLV types are defined:

This TLV carries the TEID and QFI identifying the 3gpp-5g session associated with the Interwork Endpoint. The TLV has the following format:

Where: 1 5 ST2 Tunnel Endpoint Identifier. Fixed length of 4 octets. QoS Flow Identifier. Fixed length of 1 octet.

This TLV carries the address of the interwork-side endpoint, used to look up the ISD route. It identifies the interwork-side endpoint, distinct from the mandatory Endpoint Address in the ST2 route which identifies the direct-side endpoint. The TLV has the following format:

Where: 2 4 or 16 ST2 IPv4 or IPv6 address.

This TLV carries the source address for the outgoing SRv6 and GTP encapsulation at the PE. When the source address is IPv4, an implementation MAY use a configured IPv6 prefix to construct the IPv6 address used in the SRv6 header. The TLV has the following format:

Where: 3 4 or 16 ST2 IPv4 or IPv6 address.

This document defines a BGP Extended Community known as the BGP MUP Extended Community as per . This Community is transitive across AS boundaries . The Type value is 0x0c, to be assigned by IANA from the BGP Transitive Extended Community Types registry. The Sub-Type byte distinguishes both the value format and the semantic of the community. Sub-Types 0x00, 0x01, and 0x02 identify a Direct Segment. Sub-Types 0x03, 0x04, and 0x05 identify an Interwork Segment. Within each group, the three sub-type values correspond to the 2-octet AS, IPv4 address, and 4-octet AS value formats respectively, following the conventions of and . The usage of this Extended Community is described in , , and .

The 2-octet AS specific MUP Extended Community has the following format:

Where: 0x00 (Direct Segment) or 0x03 (Interwork Segment) 2 octets. A 2-octet AS number. 4 octets. Defined by the organization holding the AS number.

The IPv4 address specific MUP Extended Community has the following format:

Where: 0x01 (Direct Segment) or 0x04 (Interwork Segment) 4 octets. An IPv4 unicast address. 2 octets. Defined by the organization holding the IPv4 address.

The 4-octet AS specific MUP Extended Community has the following format:

Where: 0x02 (Direct Segment) or 0x05 (Interwork Segment) 4 octets. A 4-octet AS number. 2 octets. Defined by the organization holding the AS number.

BGP speakers acting as a PE, and a MUP Controller MUST establish a BGP session to exchange BGP-MUP NLRIs for both, IPv4 and IPv6 AFIs. Once the session is established successfully, BGP speakers can exchange the Discovery routes as well as Session Transformed routes. This information is specific to a given routing instance. BGP-MUP SAFI is expected to work with routing instances accomodationg MUP segments. In 3GPP 5G specific case, the routing instances are depicted as N3RAN and N6DN instances defined in . The subsequent sections describes procedures of generating and processing of each route types.

The Interwork Segment Discovery route is generated by the PE when a routing instance accommodates an Interwork type MUP Segment, e.g., N3 interfaces or routes on RAN side in 3GPP 5G specific case. It generates route per each N3RAN IP prefix and stores the route in the routing instance of N3RAN. The IP prefix MAY include a gNodeB address which is connecting to the PE. The BGP AFI for BGP MP_REACH_NLRI attribute to carry the Discovery route is decided based on the AFI of the prefix. When advertising the Interwork Segment Discovery route, a PE MUST attach the export BGP Route Target Extended Community of the associated routing instance. When advertising an Interwork Segment Discovery route for a non-default Interwork Segment, the PE SHOULD attach an Interwork Segment type BGP MUP Extended Community identifying the Interwork Segment. An ISD route without a BGP MUP Extended Community represents the default Interwork Segment. When advertising the Interwork Segment Discovery route, a PE MUST use the IPv6 address of the PE as the nexthop address in the MP_REACH_NLRI attribute. The Interwork Segment Discovery route update MUST have a prefix SID attribute which the SID consists of the PE locater followed by a function. In 3GPP 5G specific case, if the BGP AFI is IPv4, the function MUST be GTP4.E , or MUST be GTP6.E if the BGP AFI is IPv6.

The Interwork Segment Discovery route is withdrawn by the PE when it detects that the MUP Segment no longer present for the N3RAN. The BGP AFI for BGP MP_UNREACH_NLRI attribute to carry the Discovery route is decided based on the AFI of the prefix. When withdrawing the Interwork Segment Discovery route, a PE MUST attach the export BGP Route Target Extended Community of the associated routing instance.

A BGP speaker acting as a PE MAY keep the received MUP Interwork Segment Discovery routes advertised from other PEs. The receiving BGP speaker will perform the importing of the received MUP Interwork Segment Discovery routes in the configured routing instance based on the Route Target extended communities. The IP prefixes for the received segments are imported into the configured routing instance table. Thereby the receiving BGP speaker can provide network connectivity between the nodes that exist in the segments. A BGP speaker MAY discard the received Interwork Segment Discovery route if the speaker fails to import the route based on the Route Target extended communities. The BGP speaker receiving the Interwork Segment Discovery routes SHOULD ignore the nexthop in the MP_REACH_NLRI attribute. However, the receiving BGP speaker MUST ensure that the value of Address filed in the NLRI is an address of the originator of the locator value in the prefix SID attribute. The originator of the locator value can be resolved from the IPv6 IGP table. If the result of the match is not identical then the receiving BGP speaker MUST consider it as a malformed NLRI and the "Treat-as-withdraw procedure of is applied. A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. When a BGP speaker receives the Interwork Segment Dicovery routes with a MP_REACH_NLRI attribute without a prefix SID attribute, then it MUST be treated as if it contained a malformed prefix SID attribute and the "Treat-as-withdraw procedure of is applied. A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. When a BGP speaker receives an MP_UNREACH_NLRI attribute update message it MUST delete the withdrawn Interwork Segment Discovery route from the routing instance table where it was created.

The Direct Segment Discovery route is generated by the PE when a routing instance accommodates a Direct type MUP Segment, e.g., N6 interface or routes on DN side in 3GPP 5G specific case. It generates the Direct Segment Discovery route per each routing instance for the MUP Segment. The address in the BGP-MUP NLRI MUST be a unique PE identifier. The BGP AFI for BGP MP_REACH_NLRI attribute to carry the Direct Segment Discovery route is decided based on the AFI of the PE identifier . When announcing the Direct Segment Discovery route, a PE MUST attach a BGP MUP Extended community of the associated routing instance. The sub-type of the Extended community is Direct-Type Segment Identifier. When advertising the Direct Segment Discovery route, a PE MUST use the IPv6 address of the PE as the nexthop address in the MP_REACH_NLRI attribute. The Direct Segment Discovery route update MUST have a prefix SID attribute which the SID consists of the PE locator followed by a function. The function MAY be End.DT4/6 or End.DX4/6.

The Direct Segment Discovery route is withdrawn by the PE when it detects that the MUP Segment no longer present for the routing instance. The BGP AFI for BGP MP_UNREACH_NLRI attribute to carry the Discovery route is decided based on the AFI of the PE identifier. When withdrawing the Direct Segment Discovery route, a BGP speaker MUST attach a BGP MUP Extended community of the associated routing instance.

A BGP speaker acting as a PE MAY keep the received MUP Direct Segment Discovery routes advertised from other PEs. The receiving BGP speaker will perform the importing of the received MUP Direct Segment Discovery routes in the configured routing instance based on the Route Target extended communities. The IP prefixes for the received segments are imported into the configured routing instance table. Thereby the receiving BGP speaker can provide network connectivity between the nodes that exist in the segments. A BGP speaker MAY discard the received Direct Segment Discovery route if the speaker fails to import the route based on the Route Target extended communities. The BGP speaker receiving the Direct Segment Discovery routes SHOULD ignore the nexthop in the MP_REACH_NLRI attribute. However, the receiving BGP speaker MUST ensure that the received nexthop value in the MP_REACH_NLRI attribute is identical to the originator of the locator value in the prefix SID attribute. The originator of the locator value can be resolved from the IPv6 IGP table. If the result of the match is not identical then the receiving BGP speaker MUST consider it as a malformed NLRI and the "Treat-as-withdraw procedure of is applied. A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. When a BGP speaker receives a MP_REACH_NLRI attribute update message with a Direct Segment Discovery route without a prefix SID attribute, than it MUST be treated as if it contained a malformed prefix SID attribute and the "Treat-as-withdraw procedure of is applied. A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. When a BGP speaker receives an MP_UNREACH_NLRI attribute update message it MUST delete the withdrawn Direct Segment Discovery route from the routing instance table where it was created.

A BGP speaker acting as a MUP Controller generates Type 1 ST route from corresponding session information through a northbound API as per . The northbound API definition for ST1 route creation is out of scope of this document. In 3GPP 5G specific case, to compose a Type 1 ST route the controller acquires UE address or prefix, Tunnel Endpoint address of GTP tunnel, TEID, and QFI for access side as input parameters from the northbound API. Controller also acquires optionally the associated Source Address. The controller decides the RD of the Type 1 ST route based on operator policy. When advertising the Type 1 ST route, the controller SHOULD attach a Route Target Extended community which the PEs are importing into the routing instance for the corresponding Direct segment. The MUP Controller MUST set the nexthop of the route to the address of the controller. The controller MUST announce this route using a AFI of the route and the SAFI of BGP-MUP to all other BGP speakers within the SRv6 domain.

A BGP speaker acting as a MUP Controller withdraws Type 1 ST route based on deletion of corresponding session information through a northbound API as per . The northbound API definition for ST1 route withdraw is out of scope of this document. In 3GPP 5G specific case, to withdraw a Type 1 ST route the controller acquires the UE address or prefix, Tunnel Endpoint address of GTP tunnel, TEID, and QFI for access side as input parameters from the northbound API. Controller also acquires optionally Source Address. The controller MUST advertise the withdraws of the Type 1 ST route. When withdrawing the Type 1 ST route, the controller SHOULD attach the Route Target Extended community which the PEs are importing into the routing instance accomodating the corresponding Direct segment to the Route Target Extended community.

A BGP speaker acting as a PE MAY keep the received MUP Type 1 ST routes advertised from the MUP Controller. The receiving BGP speaker will perform the importing of the received MUP Type 1 ST routes in the configured N6DN routing instance based on the Route Target extended communities. A BGP speaker MAY discard the received Type 1 ST route if the speaker fails to import the route based on the Route Target extended communities. In case of a BGP speaker receiving a Type 1 ST routes is a PE, the PE SHOULD use the received Tunnel Endpoint Address in this NLRI as a key to lookup the associated Interwork Segment Discovery route and extract the locator and the function in the prefix SID attribute of the Interwork route. In 3GPP 5G specific case, the PE extracts TEID, QFI, Tunnel Endpoint address and the Source address if it is present from the NLRI. A PE MAY use a locally configured Source address in an event if the Source address is not present in Type 1 ST route. The Source address is used as the source address in the SRv6 Header. The PE SHOULD generate the forwarding SID for GTP4/6.E based on the procedures mentioned in the . If the PE cannot generate the prefix SID, then it SHOULD mark the received Type 1 ST route as an invalid route. If the PE does not have a Source address for the given route, then the PE MAY hold such an invalid route until it is withdrawn. Similarly, the PE MAY hold such an invalid route until the route as a valid route upon successful generation of prefix SID. The PE receiving Type 1 ST routes SHOULD ignore the received nexthop in the MP_REACH_NLRI attribute. The PE receiving Type 1 ST routes in MP_UNREACH_NLRI attribute MUST delete all the routes from the associated routing instance. In an event where the received Type 1 ST route in MP_UNREACH_NLRI attribute does not have a Source address a receiving PE MUST delete all the matching Type 1 ST Routes with different Source addresses.

A BGP speaker acting as a MUP Controller generates Type 2 ST route from corresponding session information through a northbound API, or pre-defined configuration as per . The northbound API definition for ST2 route creation is out of scope of this document. In 3GPP 5G specific case, to compose a Type 2 ST route the controller acquires the Endpoint consists of Endpoint address of GTP tunnel and TEID for core side with the effective length of the Endpoint as input parameters. The controller decides the RD of the Type 2 ST route based on operator policy. The controller MUST attach a Route Target Extended Community of the routing instances in the PE accommodating the corresponding Interwork Segment. When advertising the Type 2 ST route for a Direct Segment, the controller SHOULD attach a Direct Segment type BGP MUP Extended Community. The community value is generated from the information received through a northbound API or a pre-defined configuration as per . The northbound API definition for receiving this information is out of scope of this document. When advertising the Type 2 ST route for a specific Interwork Segment, the controller SHOULD attach an Interwork Segment type BGP MUP Extended Community identifying the Interwork Segment. If the destination endpoint on the Interwork Segment differs from the Endpoint Address in the ST2 NLRI, the controller SHOULD also attach an Interwork Endpoint TLV carrying the destination endpoint address. A Type 2 ST route without a BGP MUP Extended Community indicates the default Interwork Segment as the destination. The controller MUST set the nexthop of the route to the address of the MUP Controller.

A BGP speaker acting as a MUP Controller withdraws Type 2 ST route based on deletion of corresponding session information through a northbound API as per . The northbound API definition for ST2 route withdraw is out of scope of this document. In 3GPP 5G specific case, to withdraw a Type 2 ST route the controller acquires the Endpoint consists of Endpoint address of GTP tunnel and TEID for core side with the effective length of the Endpoint as input parameters. The controller MUST advertise the withdraws of the Type 2 ST route. When withdrawing the Type 2 ST route, the controller SHOULD attach the same BGP MUP Extended Community that was attached when the route was advertised, together with the Route Target Extended Community of the corresponding routing instance.

A BGP speaker acting as a PE MAY keep the received MUP Type 2 ST routes advertised from the MUP Controller. The receiving BGP speaker will perform the importing of the received MUP Type 2 ST routes in the configured N3RAN routing instance based on the Route Target extended communities. A BGP speaker MAY discard the received Type 2 ST route if the speaker fails to import the route based on the Route Target extended communities. The BGP speaker receiving the Type 2 ST routes SHOULD ignore the received nexthop in the MP_REACH_NLRI attribute. A PE receiving a Type 2 ST route with a Direct Segment type BGP MUP Extended Community MUST resolve the route using the DSD routes matching that community. DSD routes MUST NOT be used to resolve Type 2 ST routes that do not carry a Direct Segment type BGP MUP Extended Community. A PE receiving a Type 2 ST route with an Interwork Segment type BGP MUP Extended Community MUST resolve the route using ISD routes that carry a matching Interwork Segment type BGP MUP Extended Community. A PE receiving a Type 2 ST route without a BGP MUP Extended Community MUST resolve the route using ISD routes for the default Interwork Segment, i.e., ISD routes that carry no BGP MUP Extended Community. When resolving a Type 2 ST route via ISD routes, the destination endpoint used for the ISD lookup is determined as follows: if the ST2 route carries an Interwork Endpoint TLV, the address in that TLV is used as the destination endpoint; otherwise, the Endpoint Address in the ST2 NLRI is used.