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
