Dear all,
For route server operators who wonder how they can transparently
passthrough NO_EXPORT / NO_ADVERTISE, the arouteserver configuration
generator now supports passthrough mode for both BIRD and OpenBGPD.
It is implemented as following:
https://github.com/pierky/arouteserver/commit/4b861b
On Wed, 11 Oct 2017 at 15:45, Nick Hilliard wrote:
> Job Snijders wrote:
> > * A few Internet Exchange RS operators need to deploy a new routing
> > policy.
>
> Then you should speak directly to the IXPs who disagree with your opinions
> and talk them into changing their opinions. As I
Job Snijders wrote:
> * A few Internet Exchange RS operators need to deploy a new routing
> policy.
Then you should speak directly to the IXPs who disagree with your
opinions and talk them into changing their opinions. As I said, this
has already been tried and it didn't work, but no-on
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 di
Job Snijders wrote:
> OK, but you are not explaining to me why the current set of RFC's can't
> be updated to encourage different NO_EXPORT behaviour on route servers
> (compared to the rest of the BGP speakers), but instead a new community
> is required.
it's because there is no consensus in the
On Wed, Oct 11, 2017 at 11:41:11AM +, Wolfgang Tremmel wrote:
> > On 10. Oct 2017, at 05:46, Job Snijders wrote:
> >
> > 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 t
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
> a
Wolfgang Tremmel wrote:
> From my reading of RFC1997 and RFC7947 the ambiguity is not really one:
>
> RFC1997 states that any community-aware BGP speaker MUT NOT advertise
> prefixes received with NO_EXPORT
> --> a route server is a BGP speaker
> --> it is community aware
>
> RFC7947 uses wordin
Hello,
> On 10. Oct 2017, at 05:46, Job Snijders wrote:
>
> 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?
From my reading of RFC1997 and RFC7
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
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:
14 matches
Mail list logo
