Thank you, Jeff.  My sincere thanks also to all who have offered their perspectives.

Jeff,

I think your observations and advice are well taken and corroborate what some others have also said.  This is also helpful for the uRPF/Source Address Validation (SAV) efforts in the IETF.  Especially your comment:  “If NO_EXPORT is being used for a prefix and global reachability is needed for the prefix, then there generally needs to be an aggregate/less-specific prefix advertised without NO_EXPORT”.  SAV techniques need to be inclusive of all feasible prefixes for source addresses (without losing directionality, i.e., without having to resort to loose uRPF) [1][2].

BCP 84 (RFC 8704) [1] also has similar (part (b) below) operational recommendation as yours above:

“… This method relies on either (a) announcements for the same prefixes (albeit some may be prepended to effect lower preference) propagating to all transit providers performing feasible-path uRPF checks or (b) announcement of an aggregate less-specific prefix to all transit providers while announcing more-specific prefixes (covered by the less-specific prefix) to different transit providers as needed for traffic engineering.”

Sriram

[1] BCP 84 (RFC 8704)  https://www.rfc-editor.org/rfc/rfc8704.pdf

[2] BAR-SAV:  https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-bar-sav-04

From: Jeff Bartig <jbartig@internet2.edu>
Sent: Wednesday, September 25, 2024 1:24 PM
To: Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov>
Cc: nanog@nanog.org
Subject: Re: Question about the use of NO_EXPORT in BGP route announcements

Hello Sriram,

The example you provide is the primary safe use of NO_EXPORT that I’ve seen used in networks. If NO_EXPORT is being used for a prefix and global reachability is needed for the prefix, then there generally needs to be an aggregate/less-specific prefix advertised without NO_EXPORT. I’ve seen plenty of unsafe uses of NO_EXPORT that result in reachability issues.

Several of the responders pointed to using NO_EXPORT as a way of preventing a peer network from advertising your route to their peers and transit neighbors. A couple of responses pointed out the danger of this approach, since it also prevents the network from advertising the route to any of its downstream/customer neighbors. If those customers are expecting to receive a full table, it won’t include the NO_EXPORT tagged routes. These customer networks may, as a result, make a poor routing decision. In a failure situation, where the customer network only has access to this almost full table, they have no path to the NO_EXPORT prefix.

NO_EXPORT isn’t the correct tool to use to both allow a peer to use a route for its customers and prevent the peer from leaking the route to its peers and transit. If we can get our router vendors to implement it, RFC9234 - Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages is a much better tool for this problem. Thanks for your work on this RFC.

Jeff

--
Jeff Bartig
Interconnection Architect
Internet2 AS11164 / AS11537
+1-608-616-9908
jbartig@internet2.edu

On 19 Sep 2024, at 12:26, Sriram, Kotikalapudi (Fed) via NANOG wrote:

For some IETF work in progress related to Source Address Validation (SAV), it is useful to know the purposes for which NO_EXPORT may be attached to routes announced in BGP, especially towards transit providers?

I know it makes sense for an AS to announce an aggregate less-specific prefix to transit providers and peers without NO_EXPORT while announcing some more-specific prefixes (subsumed under the aggregate) with NO_EXPORT towards customer ASes. But are there good reasons when an AS might announce a prefix (route) to a transit provider with NO_EXPORT attached? The IP address space in consideration here is meant to have global reachability.

Sriram