Some questions raised at the mike or in the chat window during my GROW
presentation last week on the analysis of {Regular, Large, Extended}
Communities are worth a revisit. The presentation slides are here:
https://datatracker.ietf.org/meeting/111/materials/slides-111-grow-bgp-regularextendedlarge-community-analysis-01
Comment (Jeff): Your slides have proven that stuff is being passed around in a
transitive fashion. The thing that is not necessarily a clear conclusion is
that service providers are willing to pass them around in a way that allows you
to safely use them in a transitive fashion for any given application.
Related comment (Ruediger): There is a need for consideration of what hygiene
should be applied to the communities you are propagating. Typically, people are
concerned about the hygiene of what they accept. But in a peering relationship,
you as the sender are also responsible for what you are sending; you should not
propagate without understanding the security [safety] implications. Today this
type of hygiene is generally lacking.
Response: We welcome any ideas that may help compile RC/LC/EC application types
and their propagation requirements to perform measurements against them. Also,
it is good to follow Ruediger’s suggestion and have a GROW document that
provides operator guidance on what hygiene to apply on the sender side so that
the propagation happens safely. Having said that, our measurements focused on
whether or not ASes propagate transitive communities. The results are correct
in that respect. One AS in the path may not have removed the community or
stopped propagating the route further, but the other ASes that propagated are
indeed correctly propagating transitive stuff. When it is not participating in
the specific community application, it seems correct behavior for an AS to
simply pass on the transitive community to the next AS. In general, LC and RC
are transitive (unless NO_EXPORT or NO_ADVERTISE is also present). Minor point:
The measurements also show that non-transitive ECs do not propagate; only
transitive ECs are seen propagating (slide 15).
Question (Chris): Why is it assumed (on slide 11) that the Blackhole community
is added at the origin AS?
Response: The RTBH service is requested by the prefix owner. That is why it is
assumed that it is added at the AS where the prefix is located, i.e., the
origin AS. Are there legitimate circumstances where an AS that is 2 or 3 hops
upstream from the prefix can make that request?
Thanks.
Sriram
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
