Re: [GROW] [Idr] Choice of Large vs. Extended Community for Route Leaks Solution
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) wrote: > 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 session > 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) > Sent: Wednesday, March 31, 2021 10:17 AM > To: Jeffrey Haas > Cc: Susan Hares ; i...@ietf.org; grow@ietf.org; > draft-heitz-idr-w...@ietf.org > Subject: Re: [Idr] Choice of Large vs. Extended Community for Route Leaks > Solution > > Jeff, > > Thank you for the response. My comments inline. > > >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. > > 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. > > >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. > > In the above, are you suggesting BGP Path Attribute or a new type of > Community that comes with transitivity guarantees? > > Sriram > > From: Jeffrey Haas > Sent: Wednesday, March 31, 2021 12:13 PM > To: Sriram, Kotikalapudi (Fed) > Cc: Susan Hares; i...@ietf.org; grow@ietf.org; > draft-heitz-idr-w...@ietf.org > Subject: Re: [Idr] Choice of Large vs. Extended Community for Route Leaks > Solution > > 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 >
Re: [GROW] [Idr] Choice of Large vs. Extended Community for Route Leaks Solution
> 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 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Choice of Large vs. Extended Community for Route Leaks Solution
On Wed, Mar 31, 2021 at 7:57 AM Sriram, Kotikalapudi (Fed) < kotikalapudi.sri...@nist.gov> 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 > > > --- > > Susan Hares 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 > > > > 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. > > > > 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
Re: [GROW] [Idr] Choice of Large vs. Extended Community for Route Leaks Solution
Sriram, On Wed, Mar 31, 2021 at 05:16:47PM +, Sriram, Kotikalapudi (Fed) wrote: > >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. > > 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 point Jakob follows up with in this thread strongly suggests communities are not a viable mechanism. > >...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. I've been caught napping on the changes in open policy and will have to go read this. > >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. > > 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 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Idr] Choice of Large vs. Extended Community for Route Leaks Solution
On Wed, Mar 31, 2021 at 06:02:52PM +, Jakob Heitz (jheitz) wrote: > 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. 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. > 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. 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 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Idr] Choice of Large vs. Extended Community for Route Leaks Solution
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) Sent: Wednesday, March 31, 2021 10:17 AM To: Jeffrey Haas Cc: Susan Hares ; i...@ietf.org; grow@ietf.org; draft-heitz-idr-w...@ietf.org Subject: Re: [Idr] Choice of Large vs. Extended Community for Route Leaks Solution Jeff, Thank you for the response. My comments inline. >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. 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. >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. In the above, are you suggesting BGP Path Attribute or a new type of Community that comes with transitivity guarantees? Sriram From: Jeffrey Haas Sent: Wednesday, March 31, 2021 12:13 PM To: Sriram, Kotikalapudi (Fed) Cc: Susan Hares; i...@ietf.org; grow@ietf.org; draft-heitz-idr-w...@ietf.org Subject: Re: [Idr] Choice of Large vs. Extended Community for Route Leaks Solution 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...) ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Idr] Choice of Large vs. Extended Community for Route Leaks Solution
Jeff, Thank you for the response. My comments inline. >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. 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. >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. In the above, are you suggesting BGP Path Attribute or a new type of Community that comes with transitivity guarantees? Sriram From: Jeffrey Haas Sent: Wednesday, March 31, 2021 12:13 PM To: Sriram, Kotikalapudi (Fed) Cc: Susan Hares; i...@ietf.org; grow@ietf.org; draft-heitz-idr-w...@ietf.org Subject: Re: [Idr] Choice of Large vs. Extended Community for Route Leaks Solution 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...) ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Idr] Choice of Large vs. Extended Community for Route Leaks Solution
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...) On Wed, Mar 31, 2021 at 02:56:58PM +, Sriram, Kotikalapudi (Fed) 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). > > 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 > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Choice of Large vs. Extended Community for Route Leaks Solution
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 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 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. 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. In my personal opinion, GROW is a good place to discuss the large community registry as operations people know the
