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<https://datatracker.ietf.org/doc/rfc9234/> is a much better tool for this problem. Thanks for your work on this RFC. Jeff -- Jeff Bartig Interconnection Architect Internet2 AS11164<https://as11164.peeringdb.com/> / AS11537 +1-608-616-9908 jbartig@internet2.edu<mailto: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