> I do not understand Robert's issues with this community. Let me say that I like it from operational perspective.
However from routing perspective I have doubts on how this community is going to be originated and how it is going to be used. Example 1: Hyperscaler has global POP footprint and is offering anycast services for its VPCs. So lot's of prefixes are going to be marked as such. Is the expectations that ISPs will/shall use it ? Example 2: Enterprise is injecting same prefix from different locations. It could be anycast or not. Or maybe as mentioned one host route within such /24 is true anycast. Is ISP suppose to alter their local pref according to such marking ? Even if there is no really ANYCAST service behind at all ? Example 3: How do we detect misuse and accidental or purpose marking by malicious guys in the middle ? Thx, R. On Fri, Jul 8, 2022 at 5:01 PM heasley <h...@shrubbery.net> wrote: > Thu, Jul 07, 2022 at 12:21:27PM -0400, Jeffrey Haas: > > > > > > > On Jul 7, 2022, at 11:50 AM, Robert Raszuk <rob...@raszuk.net> wrote: > > > But most if not all of those do not affect intradomain traffic > engineering rules. > > > > > > So I think Jeff's point is how much trust is needed to overwrite your > own > > > policy in selecting exit points and overwriting your EPE policy, TE > policy, Local Pref etc ... > > > > Exactly. > > > > > And I think misuse of those can happen even over direct peerings if > the overall objective is > > > to avoid double checking the community against prefix lists. > > > > Exactly. > > Meaning, please add a note to the security considerations saying don't > trust > communities (this one included) from untrusted sources. See rfc 7999 S6. > > What a receiver's policy does with the community (or several other > well-knowns or another AS'es self-defined) is their decision. The document > clearly dictates that a bgp implementation SHOULD NOT (imo MUST NOT) apply > [automatic] special handling of the community. I do not understand > Robert's > issues with this community. >
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
