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. >
If this community should be ignored when arriving via some peers then what is the point to keep it in the UPDATE MSG from those peers ? Thx, R. > 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 <rob...@raszuk.net> 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= >> 40umn....@dmarc.ietf.org> 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 <max@sdn.clinic> >>> 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 >>>> GROW@ietf.org >>>> https://www.ietf.org/mailman/listinfo/grow >>>> >>> >>> >>> -- >>> =============================================== >>> David Farmer Email:far...@umn.edu >>> 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 >>> GROW@ietf.org >>> https://www.ietf.org/mailman/listinfo/grow >>> >> > > -- > =============================================== > David Farmer Email:far...@umn.edu > 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
