Re: [Idr] some questions from {RC, LC, EC} analysis presentation in GROW

Hi Sriram,

The community attribute example 3356:666 on page 10 may not match the actual function.
"
Example: AS path = 25160 3356 12956 6147 and RC = 3356:666
 This means that the client is at AS 6147 (origin AS) and AS 3356 is the RTBH provider
 AS Distance to RTBH provider = 2
 Propagation (#hops): The Blackhole Community propagated 3 hops in this case (AS 6147 to AS 25160)
"

According to https://onestep.net/communities/as3356/
...
--------------------------------------------------------
prefix type communities
--------------------------------------------------------
3356:123 - Customer route
3356:666 - Peer route
--------------------------------------------------------
...
--------------------------------------------------------
customer traffic engineering communities - Blackhole
--------------------------------------------------------
3356:9999 - blackhole (discard) traffic

Traffic destined for any prefixes tagged with this
community will be discarded at ingress to the Level 3
network. The prefix must be one permitted by the
customer's existing ingress BGP filter.
For some router vendors the peering
must be changed to an eBGP multihop session on the Level
3 side of the connection.
...

Regards,
Shunwan

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Sriram, Kotikalapudi (Fed)
Sent: Tuesday, August 3, 2021 11:15 PM
To: GROW WG <grow@ietf.org>
Cc: IDR <idr@ietf.org>
Subject: [Idr] some questions from {RC, LC, EC} analysis presentation in GROW

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

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr