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 <n...@foobar.org> wrote: > 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 community," > > > > --> that means that NO_EXPORT_VIA_RS is "stronger" then NO_EXPORT and > > actually changes the meaning of NO_EXPORT. > > > > I know that users make stupid mistakes and this should perhaps cover > > the mistake of setting both, but IMHO with NO_EXPORT being much older > > and really well understood and used, I think NO_EXPORT should take > > precedence. > > > > (IMHO NO_EXPORT should be interpreted, and never passed through, > > independent of a router or a route server is used) > > According to rfc7947, it is a matter of local policy whether NO_EXPORT > is interpreted or passed through. This has always been the case in the > IXP world: some IXP route servers interpret NO_EXPORT and some pass it > through. So it's not correct to say that the behaviour of NO_EXPORT is > well-understood when it comes to route servers - this topic has been the > subject of a good deal of debate in the IXP community over the years, > with no resolution. > > The approach we're taking with NO_EXPORT_VIA_RS is to effectively say: > "we recommend not using NO_EXPORT because you don't know what it's going > to do. However, if you choose to use it in combination with > NO_EXPORT_VIA_RS, it's clear what your intention is, and the lack of > ambiguity with NO_EXPORT_VIA_RS when announced to a RS means that it > should override NO_EXPORT, in this and only this situation". > > > My first idea when reading this was why not make it general, why > > limit the community to route servers and not have a "SET_NO_EXPORT" > > community which directs the next hop AS to set NO_EXPORT? > > > ( I already sent this email to Nick and his answer that its limited > > to RS because otherwise some kind of TTL needs to be implemented > > makes sense) > > Limiting the community to route servers is necessary because otherwise > you'd need to implement a bgp-path TTL in order to limit the radius of > interpretation. I don't think you could safely use the as-path for > determining how far the prefix should propagate. Also there would be > other problems with prefix distribution which would be hard to solve, > e.g. what would happen in situations where an ASN's routing kit wasn't > updated to interpret this correctly? The prefix would be propagated > across asn boundaries according to standard policy, but the NO_EXPORT > interpretation might hit a couple of ASNs away, in an unexpected place. > I don't see how it would be possible to stop this from happening. > > At least if there is a requirement that this is only interpreted on > route servers and then religiously deleted on export, the scope for > creating problems is a good deal smaller. > > Nick > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow >
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
