WHAT? I'm suggesting that you not treat routes with the ANYCAST community learned from R&E peers as if they are R&E routes, but as if they are normal internet routes.
I don't think you want to require or even recommend the removal of the ANYCAST community at an EBGP boundary. Thanks On Thu, Jul 7, 2022 at 1:19 PM Robert Raszuk <[email protected]> wrote: > Hi David, > > Your case works only when subject routes coming over different R&E > network would not carry such community. Proposed NO_EXPORT does not help as > it would block advertisement of the entire prefix marked as such. > > So to fulfil your observation the draft should perhaps suggest that > ANYCAST community SHOULD (or maybe even MUST) be removed when propagating > routes over egress EBGP (from the perspective of first upstream transit). > > Many thx, > R. > > > > > On Thu, Jul 7, 2022 at 8:08 PM David Farmer <farmer= > [email protected]> wrote: > >> I think this is a useful proposal and I support it moving forward. >> >> Another use case; >> >> In the Research and Education (R&E) networking community, it is >> commonplace to set a higher local preference for routes learned from >> another R&E network, on the premise that these R&E paths will be higher >> bandwidth and/or lower congestion, even if the AS-Path is longer. However, >> if an Anycast prefix is included by another R&E network this can result in >> preferring a remote version of an Anycast service over a more local version >> of the same Anycast service. In this scenario, it is not uncommon for the >> remote Anycast service to be very remote, such as on a different continent, >> thereby defeating the purpose of Anycast. This community would easily allow >> these Anycast prefixes to either be set to normal (default) local >> preference, to be set to a lower local preference than normal assuming they >> will be remote, or even to drop the remote Anycast route altogether >> assuming they will. be very remote. >> >> Related to the trust discussion, I will note; that using this community >> to signal a lower preference for, or even dropping, a remote Anycast route >> is less of a trust issue than using the community to signal a higher >> preference for a local Anycast route. That is if the community is used to >> demote routes, it is less likely to be abused by someone seeking to >> increase traffic toward them. >> >> Thanks. >> >> >> On Tue, Jul 5, 2022 at 5:40 AM Maximilian Wilhelm <[email protected]> wrote: >> >>> Hey folks, >>> >>> after some discussion at RIPE84 we took the time to formalize a draft >>> to define a well-known BGP community to indicate a given prefix is >>> carrying Anycast traffic. The intent is to allow ISPs to do well >>> informed TE, especially in cases where they want to diverge from the >>> hot potato principle. >>> >>> You can find the draft at >>> >>> https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/ >>> >>> Happy to share this at the upcoming meeting and hear your thoughts! >>> >>> Thanks and best, >>> Max >>> >>> _______________________________________________ >>> GROW mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/grow >>> >> >> >> -- >> =============================================== >> David Farmer Email:[email protected] >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >> =============================================== >> _______________________________________________ >> GROW mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/grow >> > -- =============================================== David Farmer Email:[email protected] Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
