Hi, > the advisory nature of the community is still useful for humans when looking at the route table.
Yes I fully agree with this. In fact this is why I asked to exactly describe rules for attaching/originating it. Same prefix advertised from different locations in the topology is pretty common in enterprises. Such prefix can be /24 or /64 or less specific. There can be one host route within it acting as true anycast host/service. Thx On Thu, Jul 7, 2022 at 9:06 PM David Farmer <[email protected]> wrote: > > > On Thu, Jul 7, 2022 at 1:47 PM Robert Raszuk <[email protected]> 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 <[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 >>> =============================================== >>> >> > > -- > =============================================== > 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
