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
Reviewer: Matthew Miller
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For
Do you all want to chat about this in singapore? or just keep discussing
on-list?
do you seek WG Adoption of the draft 'now' or would you like to chat about
it a bit more first?
On Mon, Oct 9, 2017 at 5:52 PM, Nick Hilliard wrote:
> Wolfgang Tremmel wrote:
> > just reading your
Wolfgang Tremmel wrote:
> just reading your draft, a few remarks, speaking as a private internet
> citizen:
>
> "If a route server client announces a prefix tagged with both the
> NO_EXPORT and NO_EXPORT_VIA_RS communities to a route server, the
> route server MUST ignore the NO_EXPORT
Hi,
just reading your draft, a few remarks, speaking as a private internet citizen:
"If a route server client announces a prefix tagged with both the
NO_EXPORT and NO_EXPORT_VIA_RS communities to a route server, the
route server MUST ignore the NO_EXPORT community,"
--> that means that
New ID submission, as below. This is to solve a real world problem.
Comments welcome.
Nick
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: