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 com
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 m
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 draft, a few rema
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 commun
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 NO_EX
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:
