On Thu, Jul 7, 2022 at 1:47 PM Robert Raszuk <rob...@raszuk.net> wrote:
> > > 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 ? > I'm not suggesting ignoring the community from R&E peers, I'm suggesting a lower local preference or dropping the route when learned from an R&E peer. Further, regardless of the action taken in your routing policy, or even no policy action at all, the advisory nature of the community is still useful for humans when looking at the route table. Thanks > 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 >> =============================================== >> > -- =============================================== 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
