Inconsistent Route Selection Considerations:

[suehares]

Inconsistent Route Selection Considerations: Devices that recognize TLVs inconsistently may have inconsistent route selection. This should be flagged as an issue.

Features that impact BGP's route selection need significant additional scrutiny, and IDR review hasn't always been great about catching such things. The primary issue is that when such features are inconsistently deployed, or their inputs are inconsistently made use of (see comment above), BGP Speakers in the network can come to different conclusions about what the active route should be.

This can result in forwarding loops.

Features that use optional non-transitive path attributes can be more safely deployed in a network, but still require the feature to be consistently deployed within an IGP domain in many cases. This document is currently unclear about the scope of deployment, but with the focus on the ingresses, it has the feel that the intent that partial deployment is a consideration.

The text in section 6 of your document seems to confirm that partial deployment is under consideration.

See general considerations in draft-haas-idr-bgp-attribute-escape, §3 for some discussion on these points.

Note that tunneling to the nexthop can mitigate some of the forwarding loop considerations in some cases, but not all.

[suehares]

Route selection is based on route (prefix + attributes) and policy in the current version. This reduces route selection to ordinary route selection.

[lindadunbar]

Update the Section 6 with to the following:

6. Service Metadata Propagation Scope The propagation scope of the Metadata Path Attribute needs careful consideration to ensure it does not inadvertently leak to other BGP domains. According to Section 3 of [ATTRIBUTEESCAPE], it is necessary for the Route Reflector (RR) to be upgraded to constrain the propagation scope when propagating the metadata path attributes. Therefore, the Metadata Path Attribute originator sets the attribute as Non-transitive when sending the BGP UPDATE message to its corresponding RR. Non-transitive attributes are only guaranteed to be dropped during BGP route propagation by implementations that do not recognize them, ensuring that the metadata path attributes do not propagate beyond the intended scope. The RR can append the NO-ADVERTISE well-known community to the BGP UPDATE message with the Metadata Path Attribute when forwarding it to the ingress routers. This signals to the ingress nodes that the associated route's Metadata Path Attribute should not be further advertised beyond their scope. This precautionary measure ensures that the receiver of the BGP UPDATE message refrains from forwarding the received update to its peers, preventing the undesired propagation of the information carried by the Metadata Path Attribute. In addition, the Service Metadata propagation can be further constrained to a set of ingress nodes that are interested in the services. For example, for each registered low-latency Service, BGP RT Constrained Distribution can be used to form the Group interested in the Service. The "Service ID", an IP address prefix, is the Route Target. When an ingress router receives the first packet of a flow destined to a Service ID (i.e., IP prefix), the ingress router sends a BGP UPDATE that advertises the Route Target membership NLRI per . The ingress router must assign a Timer for the Service ID, as the UE that uses the Service ID might move away. Upon receiving a packet destined for the Service ID, the ingress router must refresh the Timer. The ingress router must send a BGP Withdraw UPDATE for the Service ID upon expiration of the Timer. specifies SAFI=132 for the Route Target membership NLRI Advertisements.