Subject: [Idr] Choice of Large vs. Extended Community for Route Leaks Solution

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 31 Mar 2021 14:56:58 +0000

Hi Sue,

Thanks for the detailed thoughts you have shared on the IDR list about the WKLC draft and route leaks solution draft (while also responding to Brian’s post).

At one point in the past, the route leaks solution needed 8 bytes of user data space to accommodate two ASNs but then there was a design change (more than a year ago) and the current draft [1] requires only 4 bytes of user data space (one ASN). So, it seems possible to use a Transitive Extended Community instead of WKLC.

We (authors of the WKLC draft) can continue working on creating an IANA WKLC registry for the future but I think the route leaks solution draft can switch to using Transitive Extended Community. Especially, if that could help expedite the route leaks draft and its deployment? I would like to seek advice regarding that (I'm cc'ing GROW also here). 

One question is… even after IANA allocation of a Transitive Extended Community for route leaks, there may still be additional effort needed to get the operators to truly treat the EC as *transitive* so that it propagates at least a few hops. How do we accomplish that? Write a BCP in GROW strongly recommending operators to implement default policy to ensure transitivity? We would like to hear people's thoughts about that? 

Thank you.

Sriram            

[1] Route leaks solution draft (in GROW): https://datatracker.ietf.org/doc/html/draft-ietf-grow-route-leak-detection-mitigation-04 

---------------------------------------------------------------------------------------

Susan Hares <[email-masked]> Fri, 26 March 2021 21:28 UTCShow header
Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23) - no consensus for adoption

Brian and co-authors: 

As I typed my response to Brian’s questions, I found it was turning into a copy of my chair’s response to the WG adoption call.   Therefore, I have just included my review as the shepherd to Brian’s request. 

Cheers, Sue 

<WG chair hat on> 

Summary: 

There is no consensus on adoption this draft in its current form.   The IDR co-chairs remain committed to the route-leak mitigation work and large communities. 

<WG chair hat on> 

Would 255 ASNs instead of  original request:

Even requesting 255 ASNs needs substantial justification.  For the route leaks, we  anticipated 2-8 would be sufficient.  As you recall when we started this approach,  I talked with Alvaro (our AD) and IANA to determine if IDR could request these special ASNs. 

However, asking for 255 ASNs you would need: 

a) a draft indicating the request for the ASNs, 

b) support of the draft from grow (WG adoption, WG LC) 

c) support of the draft from IDR (WG adoption, WG LC) 

255 ASNs should be vetted IDR, grow, and operator community.  If you go this way, I would suggest the Grow chairs also ask the *NOGs (NANOG, RIPE, JANOG..) if allocating 255 ASNs is ok. 

Route leaks: 

As you indicated, the route-leaks needs a small amount of ASNs.  As you recall from our discussion the IDR chairs at the time (John Scudder and myself) felt would could use the drafts in IDR and Grow to push for 2-4 special purpose ASNs.   My current co-chairs agree to support this initial allocation. 

Large community changes: 

I quietly listened to the WG adoption call on this draft because it mattered what the ISPs and implementers said.  The Large communities (RFC8092) had overwhelming support from the operation community for 12 octet value with simple encoding.  

The RFC8092 encoding does not have support for transitive nature because the operator community wished to have a simple encoding.  After placing the WG LC during IETF and immediately after I did not hear an outcry from the operations community to change the simple nature of Large communities.  

Well know community registry: 

The original large community (RFC8092) creation did not take the time to create a “well-known community” registry.  My reading of the community effort that time was a “well-known community” registry was acceptable to the community, but not at the cost of slowing down deployment of large communities.  The hard work of getting consensus on the size and range for large communities needs to happen prior to asking IANA to create the registry. 

Possible next steps: 

1. Break the -4 ASNs away from the draft and append the request to existing grow drafts.   Section 6 of (draft-grow-route-leak-detection-mitigation-04.txt) could request specific ASNs.  

2.  Working with IDR/Grow to create a well-known Large Community registry discussing whether well-known community are just values registered or a range.   

3.  Work to get 255 ASNs approved through IDR/GROW

4.  Use a BGP attribute to solve the transitivity. 

The authors can contact the idr co-chairs as a group or grab one of the IDR co-chairs for a chat.   The IDR co-chairs meet weekly.   Let us know what we can do to help you. 

 <WG co-chair hat off> 

<WG participant hat on> 

In my personal opinion, GROW is a good place to discuss the large community registry as operations people know the requirements for the size of registry.   

Cheers, Sue

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 31 Mar 2021 12:13:58 -0400

Sriram,

(Clearly I'm not Sue...)

Extending the observation I've just made to Gyan, the headache you're going
through is trying to avoid the work of creating a new attribute.  A result
of this is a lot of work trying to proscriptively change how people operate
their networks for more general features.

Extended communities have functionally behaved as more of a protocol control
mechanism in their general history.  They already have behaviors that permit
them to be selectively transitive or non-transitive across ASes.
Operationally, they MAY be stripped by policy, but sanitization practices
for them are significantly less codified than RFC 1997 communities.  You can
thus just get a FCFS extended community from a transitive space TODAY and
it'd probably do most of what you want.  One of the beneficial properties
that extended communities have is the transitivity is at least understood
and well deployed.

That said, there's still no guarantee that some operator may choose to just
delete them all at an ASBR.

A discussion I'd suggest is that we've had a need for a "BGP routing
security" attribute where we can put these various proposals:
- It's not a victim of existing community practices.
- Policy might still interact with it, but the baseline maintenance
  expectations can be set for it.
- It can be extensible so new components can be added incrementally.

While I understand a motivation for putting this in communities is "faster
deployment", take the other example from the life of large communities: when
there's sufficient interest, the feature will show up pretty fast.

-- Jeff (the best time to plant a tree is ten years ago. the second best
time is now...)

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 31 Mar 2021 17:16:47 +0000

Jeff,

Thank you for the response. My comments inline.

>You can thus just get a FCFS extended community from a
>transitive space TODAY and

I was hoping for a confirmation of that nature. So, that is good to hear.

>That said, there's still no guarantee that some operator may choose to just delete them all at an ASBR.

Yep. It is not a perfect world. But are you suggesting that no community-based approach (EC or LC or ?) is worth pursuing? 

>...the headache you're going through is trying to avoid the work of creating a new attribute. 

There is already a separate draft in IDR that has passed WGLC, and it uses a new transitive BGP Path Attribute 'Only to Customer (OTC)':
https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-15
We view that as a longer-term solution, while the EC/LC-based approach is meant to be deployed quickly.  

>- It can be extensible so new components can be added incrementally.

In the above, are you suggesting BGP Path Attribute or a new type of Community that comes with transitivity guarantees?

Sriram
________________________________________
From: Jeffrey Haas <[email-masked]>
Sent: Wednesday, March 31, 2021 12:13 PM
To: Sriram, Kotikalapudi (Fed)
Cc: Susan Hares; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] Choice of Large vs. Extended Community for Route Leaks Solution

Sriram,

(Clearly I'm not Sue...)

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 31 Mar 2021 18:02:52 +0000

No community is transitive.
Not even the transitive extended communities.

In all BGP code I've worked in, not just Cisco, a configuration
is required to send communities of any kind to an ebgp session.
By default, no communities are sent to ebgp sessions.
That's a good thing, because network operators don't want
junk in the routes transiting across their networks, causing
churn and memory consumption.

Path attributes are transitive.
However, several years ago, approximately coinciding with the
development of RFC7660, there was massive thrust to get attributes
blocked too. Now we implement path attribute filtering
and many network operators use it.

Regards,
Jakob.

-----Original Message-----
From: Sriram, Kotikalapudi (Fed) <[email-masked]> 
Sent: Wednesday, March 31, 2021 10:17 AM
To: Jeffrey Haas <[email-masked]>
Cc: Susan Hares <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] Choice of Large vs. Extended Community for Route Leaks Solution

Jeff,

Sriram

Sriram,

(Clearly I'm not Sue...)

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 31 Mar 2021 18:00:48 -0400

> churn and memory consumption.

Contrarily, the implementations I've worked on don't have this behavior.
But it's still a highly relevant point and perhaps what should probably be a
useful rule of thumb across IETF working groups that deal with BGP:

Because such a knob exists on multiple implementations, communities 
SHOULD NOT be used for any protocol transient signaling behaviors.

> and many network operators use it.

Sadly, also yes.

At least in my case, every discussion I have about the feature I note that
it is toxic to the incremental deployment of new features in BGP.  And
similarly, that it is a toxic use case for someone paying them as a transit
provider.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 31 Mar 2021 18:09:42 -0400

Sriram,

> Yep. It is not a perfect world. But are you suggesting that no community-based approach (EC or LC or ?) is worth pursuing? 

The point Jakob follows up with in this thread strongly suggests communities
are not a viable mechanism.

> We view that as a longer-term solution, while the EC/LC-based approach is meant to be deployed quickly.  

I've been caught napping on the changes in open policy and will have to go
read this.

> In the above, are you suggesting BGP Path Attribute or a new type of Community that comes with transitivity guarantees?

The biggest headache with getting new features into BGP as attributes is the
first bit of code point assignment.  If such a feature has an extension
mechanism, new things within that path attribute are usually much easier to
get deployed, and it helps their development and deployment velocity.

We're not exactly low on BGP Path Attribute code points.  But it'd be nice
if the incremental deployment story for bgp security features is better than
the incremental micro feature of the day.  Minimally, as Jakob notes, it'll
make the deployment story nicer for the service providers that have harmed
incremental deployment of new features by proactive filtering.

-- Jeff

---

From: Brian Dickson <[email-masked]>
Date: Wed, 31 Mar 2021 15:10:08 -0700

On Wed, Mar 31, 2021 at 7:57 AM Sriram, Kotikalapudi (Fed) <
[email-masked]> wrote:

> Hi Sue,
>
> Thanks for the detailed thoughts you have shared on the IDR list about the
> WKLC draft and route leaks solution draft (while also responding to Brian’s
> post).
>
> At one point in the past, the route leaks solution needed 8 bytes of user
> data space to accommodate two ASNs but then there was a design change (more
> than a year ago) and the current draft [1] requires only 4 bytes of user
> data space (one ASN). So, it seems possible to use a Transitive Extended
> Community instead of WKLC.
>
> We (authors of the WKLC draft) can continue working on creating an IANA
> WKLC registry for the future but I think the route leaks solution draft can
> switch to using Transitive Extended Community. Especially, if that could
> help expedite the route leaks draft and its deployment? I would like to
> seek advice regarding that (I'm cc'ing GROW also here).

Sorry to argue in public, but I disagree very strongly on the second part
here.

We would like to continue proceeding with use of a LC range for
implementation, using a single (or small number) of Global Administrator
values.

I think we should request that a small block of GAs surrounding the initial
assignments be tentatively marked something like Reserved for IANA
assignment.
That is different from actually establishing a registry or assigning them
specifically for WKLCs, but would be compatible with subsequent WKLC work.

The move to using LC values was precipitated by the observation that the
path for getting attributes deployed would be very long, and that operators
(actual network operators) are looking for a solution which can be deployed
*now*.

Nothing has changed in this regard; the WKLC draft is IMHO still the right
path, and only the size of the initial allocation is problematic.

Having 1-4 GA values (from the 32-bit range of potential values) is not
burdensome IMNSHO, and is a lot less of a concern than the 1/64 (or 1/16)
of the range of 32-bit ASNs originally requested/suggested.

If we can all agree that 1-4 GA values assigned for this is acceptable, I
suggest a revised version of the draft and assessment of consensus on the
revised draft for adoption and last call.

LC is the ONLY viable path, given the nebulous state of implementation and
use for EC/WC or attributes. LC is already deployed, and assigning a few
GAs by IDR is the only roadblock to the draft in GROW getting approved.

Brian

>
>
> One question is… even after IANA allocation of a Transitive Extended
> Community for route leaks, there may still be additional effort needed to
> get the operators to truly treat the EC as *transitive* so that it
> propagates at least a few hops. How do we accomplish that? Write a BCP in
> GROW strongly recommending operators to implement default policy to ensure
> transitivity? We would like to hear people's thoughts about that?
>
> Thank you.
>
> Sriram
>
> [1] Route leaks solution draft (in GROW):
> https://datatracker.ietf.org/doc/html/draft-ietf-grow-route-leak-detection-mitigation-04
>
>
> As I typed my response to Brian’s questions, I found it was turning into a
> copy of my chair’s response to the WG adoption call.   Therefore, I have
> just included my review as the shepherd to Brian’s request.
>
> Cheers, Sue
>
> <WG chair hat on>
>
> Summary:
>
> There is no consensus on adoption this draft in its current form.   The
> IDR co-chairs remain committed to the route-leak mitigation work and large
> communities.
>
> <WG chair hat on>
>
> Even requesting 255 ASNs needs substantial justification.  For the route
> leaks, we  anticipated 2-8 would be sufficient.  As you recall when we
> started this approach,  I talked with Alvaro (our AD) and IANA to determine
> if IDR could request these special ASNs.
>
> 255 ASNs should be vetted IDR, grow, and operator community.  If you go
> this way, I would suggest the Grow chairs also ask the *NOGs (NANOG, RIPE,
> JANOG..) if allocating 255 ASNs is ok.
>
> Route leaks:
>
> As you indicated, the route-leaks needs a small amount of ASNs.  As you
> recall from our discussion the IDR chairs at the time (John Scudder and
> myself) felt would could use the drafts in IDR and Grow to push for 2-4
> special purpose ASNs.   My current co-chairs agree to support this initial
> allocation.
>
> Large community changes:
>
> I quietly listened to the WG adoption call on this draft because it
> mattered what the ISPs and implementers said.  The Large communities
> (RFC8092) had overwhelming support from the operation community for 12
> octet value with simple encoding.
>
> The RFC8092 encoding does not have support for transitive nature because
> the operator community wished to have a simple encoding.  After placing the
> WG LC during IETF and immediately after I did not hear an outcry from the
> operations community to change the simple nature of Large communities.
>
> The original large community (RFC8092) creation did not take the time to
> create a “well-known community” registry.  My reading of the community
> effort that time was a “well-known community” registry was acceptable to
> the community, but not at the cost of slowing down deployment of large
> communities.  The hard work of getting consensus on the size and range for
> large communities needs to happen prior to asking IANA to create the
> registry.
>
> Possible next steps:
>
> 1. Break the -4 ASNs away from the draft and append the request to
> existing grow drafts.   Section 6 of
> (draft-grow-route-leak-detection-mitigation-04.txt) could request specific
> ASNs.
>
> 2.  Working with IDR/Grow to create a well-known Large Community registry
> discussing whether well-known community are just values registered or a
> range.
>
> The authors can contact the idr co-chairs as a group or grab one of the
> IDR co-chairs for a chat.   The IDR co-chairs meet weekly.   Let us know
> what we can do to help you.
>
>  <WG co-chair hat off>
>
> <WG participant hat on>
>
> In my personal opinion, GROW is a good place to discuss the large
> community registry as operations people know the requirements for the size
> of registry.
>
> Cheers, Sue
>

---

From: Randy Bush <[email-masked]>
Date: Wed, 31 Mar 2021 16:26:06 -0700

> The point Jakob follows up with in this thread strongly suggests
> communities are not a viable mechanism.

communities are rarely a viable mechanism.  too malleable, forgable,
...  once again, see our paper.

randy

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 31 Mar 2021 22:19:27 -0400

Correction

BGP communities  are optional transitive.  If all communities were not
transitive the knob would not exist in any implementation such as Cisco and
maybe others that have a “send-community” knob requirements manual CLI
command to propagate communities.

BGP communities going between administrative domains public or private are
mailable and not reliable as operators can and do often delete and reset
communities if desired. Agreed.

On Wed, Mar 31, 2021 at 2:03 PM Jakob Heitz (jheitz) <jheitz=
[email-masked]> wrote:

> By default, no communities are sent to ebgp session
> Yep. It is not a perfect world. But are you suggesting that no
> community-based approach (EC or LC or ?) is worth pursuing?
>
> There is already a separate draft in IDR that has passed WGLC, and it uses
> a new transitive BGP Path Attribute 'Only to Customer (OTC)':
> In the above, are you suggesting BGP Path Attribute or a new type of
> Community that comes with transitivity guarantees?
>
> Sriram
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*