Hi Jeff, пн, 8 июл. 2019 г. в 22:22, Jeffrey Haas <jh...@pfrc.org>:
> Alexander, > > On Mon, Jul 08, 2019 at 06:06:15PM +0300, Alexander Azimov wrote: > > - A single community is used for both route leak prevention, and > > detection; > > - All route leaks MUST be rejected; > > - L is removed since we don't need it in this case. > > A default policy of reject all leaks makes sense, I think. > > I have a slightly different view of what has been called L above: > Programmatically determining that you are the network of last resort to not > cut off an ASes prefix is tricky. This is what the NOC phones get used > for. > > What's somewhat desired, I think, is dealing with the result of that NOC > phone call: An attestation that a provider has permitted a detected leak. > Consider it an "override". > If you are already calling it's better to call not the upper upstream provider who dropped the leak, but the 'intermediate' provider who accepted the leak. Anyway, I'm planning to have another topology study and check how many prefixes may be theoretically affected with such anomaly. > An aside question: For service providers that are "peer" types, how are > their own internal networks intended to be flagged? > If I got your question correctly, there is no marking (or no additional marking) before prefix is sent to 'external' neighbor. It is also true for networks with multiple ASNs under control. -- Best regards, Alexander Azimov
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
