Anno domini 2022 Robert Raszuk scripsit: Hi Robert,
replying inline to answer to your points. > Thank you for publishing this draft. I have few questions after reading it. > > 1. If I have /24 and I advertise it over N peerings N>1 to my ISP from my > DMZ does it automatically become ANYCAST prefix ? I'd go with the Wikipedia defintion here Anycast is a network addressing and routing methodology in which a single destination IP address is shared by devices (generally servers) in multiple locations. So if you advertise the same prefix on multiple upstream but from the same site, I'd say it's unicast and not anycast. Technically it should be Anycast once you advertise it in two or more distinct sites. > 1a. Note that I may have just one real host route in this /24 which I > consider a true anycast destination. I'd consider the Anycast definition here from a DFZ point of view as noted above. So if you anycast stuff internally to your network I guess that does not fall into that category if not also announced from several distinct locations. Does that make sense? > 2. Are you proposing to make any changes to best path selection based on > the presence of the specified community ? No. The intention is to only allow operators to influence best path selection by means of import/export policies if they deem that a good idea. > 3. As I am sure you realize hot-potato or not-so-hot-potato routing is the > result of choosing a best paths with a given next hop. Consideration of > correct metric to this next hop is what makes it hot or not. Now with the > use of route reflection where RRs are not in the data path that metric is > normally fake (possibly hot from perspective of RR but not necessarily hot > from the perspective of the client) . That is why I wrote RFC9107 ( > https://datatracker.ietf.org/doc/rfc9107/) to allow to use the correct > metric. Are mandating use of such tools for prefixes marked with ANYCAST > community ? Hmm, I guess if operators wanted to leverage the ANYCAST community in such an environment it might make sense to do so on the RRs. > 4. Or alternatively to #3 are you suggesting to always use ADD-PATHS ALL > for all prefixes marked with ANYCAST community ? In the RR case I presume? If so that could be an option which could make sense to add to the proposal as one option. I'm not sure if a general suggestion could be given here. > Bottom line you have written good justification why such marking makes > sense. But currently draft is missing more description when to mark when > advertising given prefix over eBGP sessions (redundant advertisement is a > norm these days). There is also no description on expected BGP > implementation behavior when such prefixes marked with ANYCAST community > are received by BGP speaker. I agree a definition of what is considered anycast with respect to this document would be of value. I'll try to add some details here. Thanks for you feedback! Cheers, Max _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
