Hi all,
> because:
>
> - the RFCs are formally ambiguous, dating way back to RFC1863 (which
> is acknowledged to be experimental, but documented the practices going
> back to the mid 1990s)
>
> - each IXP which has gone one way or the other has carefully
> considered reasons for doing what they did
>
> - because of this, it will not be possible to reach consensus on
> interpreting NO_EXPORT or passing it through (we have tried)
>
> - the authors of this ID believe that the only way to fix this problem
> is to acknowledge that it cannot be fixed, then move on.
Alright, it seems an Internet-Draft is warranted to clarify or improve
what route servers should do with certain well-known communities. I
support solving that problem.
The way I look at it is quite simple, let's assess how big the
populations are that need to do work:
Option A) An I-D that clarifies the behaviour of NO_EXPORT on a RS (and
updates RFC1997 and RFC7947)
Option B) An I-D that defines behaviour for a new flavor of NO_EXPORT
(NO_EXPORT_VIA_RS) on a RS (and updates RFC1997 and RFC7947)
Option A's impact:
* A few Internet Exchange RS operators need to deploy a new routing
policy.
Option B's impact:
* Every non-RFC7947 EBGP speaker needs to start scrubbing the new
NO_EXPORT_VIA_RS community.
* Every IXP RS operator needs to deploy a new configuration.
* Every IXP RS participant needs to memorize that there is a new
specific NO_EXPORT-ish community.
In other words, I don't think it is fair to follow option B
(draft-hilliard-grow-no-export-via-rs-00) because it causes the most
work.
For the route server operators that want to follow RFC 1997 to the
letter: honoring NO_EXPORT on a RS is a fringe activity. If there really
is a usecase to do so the IX should offer a locally significant
community. Also realize that if RFC 1997 is updated according to option
A, not honoring NO_EXPORT means you'll be compliant with the standards.
Option A aligns with the principle of least astonishment. I look forward
to draft-hilliard-grow-no-export-via-rs-01 which drops the definition of
a new NO_EXPORT-ish community and simply defines the pragmatic,
participant-friendly behaviour that RFC7947 BGP speakers should apply.
Kind regards,
Job
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
