we've discussed this several times in the IXP community, with no general agreement. In terms of public positions, for example:
- DE-CIX honours RFC1997 to the letter: > The well-known BGP Communities NO-EXPORT (65535:65281) and > NO-ADVERTISE (65535:65282) are also honored meaning that a BGP > announcement marked by one of these communities is not re-distributed > to any peer. (https://www.de-cix.net/en/locations/united-states/dallas/routeserver-guide) - Netnod documented problems with this for their DNS root server, while expressing the opposite opinion to DE-CIX > Some route-servers honors the communities as if they where the receivers > (like > no-export - duh!). see page 24 of https://www.netnod.se/sites/default/files/aboutnetnod/Netnod_updates/Netnod_update_spring_meeting_2014.pdf - MSK-IX realised the ambiguity and rolled their own (https://kb.msk-ix.ru/en/ix/services/route-server/) Other IXPs go one way or the other. There really is no consistency here, hence the I-D. Nick Job Snijders wrote: > Hi nick, > > Have you considered just updating RFC 7947 to resolve the described > ambiguity by stating that a route server SHOULD pass the NO_EXPORT > community unaltered, rather than interpret it or block it? > > The advance of this approach would be that a portion of deployed route > servers are already compliant, as where using a new NO_EXPORT_VIA_RS > community would require every route server to be updated. > > From the route server client perspective it may also be simpler if there > is just one “no export function” community instead of multiple. > > Why is there no consensus amongst route server operators on what the > correct behavior is? Can you provide a citation? > > Kind regards, > > Job > > On Mon, 9 Oct 2017 at 16:02, Nick Hilliard <n...@foobar.org > <mailto:n...@foobar.org>> wrote: > > New ID submission, as below. This is to solve a real world problem. > > Comments welcome. > > Nick > > internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> wrote: > > A new version of I-D, draft-hilliard-grow-no-export-via-rs-00.txt > > has been successfully submitted by Nick Hilliard and posted to the > > IETF repository. > > > > Name: draft-hilliard-grow-no-export-via-rs > > Revision: 00 > > Title: The BGP NO_EXPORT_VIA_RS Community for Route > Servers > > Document date: 2017-10-08 > > Group: Individual Submission > > Pages: 5 > > URL: > > https://www.ietf.org/internet-drafts/draft-hilliard-grow-no-export-via-rs-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-hilliard-grow-no-export-via-rs/ > > Htmlized: > https://tools.ietf.org/html/draft-hilliard-grow-no-export-via-rs-00 > > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-hilliard-grow-no-export-via-rs-00 > > > > > > Abstract: > > This document describes a BGP Well-known Community called > > NO_EXPORT_VIA_RS. This community allows BGP route server > clients to > > instruct an Internet Exchange BGP Route Server to tag prefixes > > destined for other route server clients with the NO_EXPORT > Well-Known > > Community. This mechanism allows route server clients to > > transitively control distribution of their prefixes in other > > Autonomous Systems connected to the Internet Exchange Route Server. > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at > tools.ietf.org <http://tools.ietf.org>. > > > > The IETF Secretariat > > > > _______________________________________________ > GROW mailing list > GROW@ietf.org <mailto:GROW@ietf.org> > https://www.ietf.org/mailman/listinfo/grow > _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
