Re: [GROW] Choice of Large vs. Extended Community for Route Leaks Solution
Jakob, Thanks. I was expecting this question. We will work on a recursive path analysis to answer it. Brian's suggestion also will be considered. The data crunching may take a week or so. My hunch was that when the AS path length is 5 or 6 or more, the ASes at the far end (most recently added) are not likely the savvy ones to be doing EC/LC but more likely the earlier ASes added the EC/LC. We'll see what the more detailed data analysis reveals. Sriram From: Jakob Heitz (jheitz) Sent: Friday, April 2, 2021 2:38 AM To: Sriram, Kotikalapudi (Fed) Cc: Jeffrey Haas; Susan Hares; i...@ietf.org; draft-heitz-idr-w...@ietf.org; grow@ietf.org; a.e.azi...@gmail.com; Brian Dickson Subject: Re: Choice of Large vs. Extended Community for Route Leaks Solution When the collector sees a route with AS-PATH length 5 with a community on it, that does not imply that the community traveled through 5 AS hops. The community could have been added at any of the ASes in the path. Where does the data show that any communities transited any AS boundaries? Regards, Jakob. > On Apr 1, 2021, at 2:06 PM, Sriram, Kotikalapudi (Fed) > wrote: > > There may be a knob that AS operators have for permitting transitivity, but > we need to look at measurements to understand whether or not operators > actually allow transitivity to EC and LC. > > NIST BGP measurements (thanks to my colleague Lilia Hannachi) were shared on > the GROW list in May 2020: > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fgrow%2FJPD1-hhSvVXIZbUlNQ_1hmzD6IA%2Fdata=04%7C01%7Ckotikalapudi.sriram%40nist.gov%7C7e0ddfc991ff4aa54f9308d8f5a1e8e7%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637529423059320205%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=WPgxMhjSfAx%2FueDd487sVRqVWCAYY%2FMIF51gzbf%2Bm7Q%3Dreserved=0 > > A portion is copied below. The AS path length (# unique ASes) distributions > for BGP updates with Communities (Regular, Large, and Extended) are shown > here. It is evident that both LC and EC propagate multiple AS hops. Mass > stripping of LC or EC at the first hop is not evident. The peak happens at > AS path length 4 or 5 and that is good. That is the behavior that is helpful > for route leak solution. The solution can still function even if some ASes > strip. We can do some more detailed studies if needed. > > * > RIPE-RIS: Community ANALYSIS (Collector : rrc03 From 2020-04-30 00:00 To > 2020-04-30 00:55) > * > # Updates = 1075583 (Total) > # (Regular) COMMUNITY = 859239 (79.89%) > AS path length distribution =1: 170 (0.02%)2: 44803 (5.21%)3: > 141072 (16.42%)4: 276271 (32.15%)5: 238325 (27.74%)6: 114158 > (13.29%)7: 31365 (3.65%)8: 9018 (1.05%)9: 2690 (0.31%)10: 811 > (0.09%)11: 358 (0.04%)12: 169 (0.02%)13: 22 (0%)14: 7 (0%) > > # LARGE_COMMUNITY = 152818 (14.21%) > AS path length distribution =2: 5655 (3.7%)3: 17205 (11.26%)4: > 54372 (35.58%)5: 45492 (29.77%)6: 22065 (14.44%)7: 6422 (4.2%) > 8: 1068 (0.7%)9: 397 (0.26%)10: 71 (0.05%)11: 35 (0.02%)12: > 26 (0.02%)13: 6 (0%)14: 4 (0%) > > # EXTENDED COMMUNITIES = 44606 (4.15%) > AS path length distribution =2: 2269 (5.09%)3: 7435 (16.67%)4: > 17657 (39.58%)5: 11600 (26.01%)6: 3967 (8.89%)7: 1221 (2.74%) > 8: 371 (0.83%)9: 57 (0.13%)10: 19 (0.04%)11: 8 (0.02%)12: 1 > (0%)13: 1 (0%) > * > > Sriram ___ 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
When the collector sees a route with AS-PATH length 5 with a community on it, that does not imply that the community traveled through 5 AS hops. The community could have been added at any of the ASes in the path. Where does the data show that any communities transited any AS boundaries? Regards, Jakob. > On Apr 1, 2021, at 2:06 PM, Sriram, Kotikalapudi (Fed) > wrote: > > There may be a knob that AS operators have for permitting transitivity, but > we need to look at measurements to understand whether or not operators > actually allow transitivity to EC and LC. > > NIST BGP measurements (thanks to my colleague Lilia Hannachi) were shared on > the GROW list in May 2020: > https://mailarchive.ietf.org/arch/msg/grow/JPD1-hhSvVXIZbUlNQ_1hmzD6IA/ > > A portion is copied below. The AS path length (# unique ASes) distributions > for BGP updates with Communities (Regular, Large, and Extended) are shown > here. It is evident that both LC and EC propagate multiple AS hops. Mass > stripping of LC or EC at the first hop is not evident. The peak happens at > AS path length 4 or 5 and that is good. That is the behavior that is helpful > for route leak solution. The solution can still function even if some ASes > strip. We can do some more detailed studies if needed. > > * > RIPE-RIS: Community ANALYSIS (Collector : rrc03 From 2020-04-30 00:00 To > 2020-04-30 00:55) > * > # Updates = 1075583 (Total) > # (Regular) COMMUNITY = 859239 (79.89%) > AS path length distribution =1: 170 (0.02%)2: 44803 (5.21%)3: > 141072 (16.42%)4: 276271 (32.15%)5: 238325 (27.74%)6: 114158 > (13.29%)7: 31365 (3.65%)8: 9018 (1.05%)9: 2690 (0.31%)10: 811 > (0.09%)11: 358 (0.04%)12: 169 (0.02%)13: 22 (0%)14: 7 (0%) > > # LARGE_COMMUNITY = 152818 (14.21%) > AS path length distribution =2: 5655 (3.7%)3: 17205 (11.26%)4: > 54372 (35.58%)5: 45492 (29.77%)6: 22065 (14.44%)7: 6422 (4.2%) > 8: 1068 (0.7%)9: 397 (0.26%)10: 71 (0.05%)11: 35 (0.02%)12: > 26 (0.02%)13: 6 (0%)14: 4 (0%) > > # EXTENDED COMMUNITIES = 44606 (4.15%) > AS path length distribution =2: 2269 (5.09%)3: 7435 (16.67%)4: > 17657 (39.58%)5: 11600 (26.01%)6: 3967 (8.89%)7: 1221 (2.74%) > 8: 371 (0.83%)9: 57 (0.13%)10: 19 (0.04%)11: 8 (0.02%)12: 1 > (0%)13: 1 (0%) > * > > Sriram ___ 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 Thu, Apr 1, 2021 at 2:06 PM Sriram, Kotikalapudi (Fed) < kotikalapudi.sri...@nist.gov> wrote: > There may be a knob that AS operators have for permitting transitivity, > but we need to look at measurements to understand whether or not operators > actually allow transitivity to EC and LC. > > NIST BGP measurements (thanks to my colleague Lilia Hannachi) were shared > on the GROW list in May 2020: > https://mailarchive.ietf.org/arch/msg/grow/JPD1-hhSvVXIZbUlNQ_1hmzD6IA/ > > A portion is copied below. The AS path length (# unique ASes) > distributions for BGP updates with Communities (Regular, Large, and > Extended) are shown here. It is evident that both LC and EC propagate > multiple AS hops. Mass stripping of LC or EC at the first hop is not > evident. The peak happens at AS path length 4 or 5 and that is good. That > is the behavior that is helpful for route leak solution. The solution can > still function even if some ASes strip. We can do some more detailed > studies if needed. > > * > RIPE-RIS: Community ANALYSIS (Collector : rrc03 From 2020-04-30 00:00 To > 2020-04-30 00:55) > * > # Updates = 1075583 (Total) > # (Regular) COMMUNITY = 859239 (79.89%) > AS path length distribution =1: 170 (0.02%)2: 44803 (5.21%)3: > 141072 (16.42%)4: 276271 (32.15%)5: 238325 (27.74%)6: 114158 > (13.29%)7: 31365 (3.65%)8: 9018 (1.05%)9: 2690 (0.31%)10: > 811 (0.09%)11: 358 (0.04%)12: 169 (0.02%)13: 22 (0%)14: 7 > (0%) > > # LARGE_COMMUNITY = 152818 (14.21%) > AS path length distribution =2: 5655 (3.7%)3: 17205 (11.26%)4: > 54372 (35.58%)5: 45492 (29.77%)6: 22065 (14.44%)7: 6422 (4.2%) > 8: 1068 (0.7%)9: 397 (0.26%)10: 71 (0.05%)11: 35 (0.02%) > 12: 26 (0.02%)13: 6 (0%)14: 4 (0%) > > # EXTENDED COMMUNITIES = 44606 (4.15%) > AS path length distribution =2: 2269 (5.09%)3: 7435 (16.67%)4: > 17657 (39.58%)5: 11600 (26.01%)6: 3967 (8.89%)7: 1221 (2.74%) > 8: 371 (0.83%)9: 57 (0.13%)10: 19 (0.04%)11: 8 (0.02%)12: > 1 (0%)13: 1 (0%) > * > One main issue will be the use of LC vs WC vs regular communities, among the largest networks (e.g. networks nominally at the tier-1 designation). Going from e.g. a wikipedia page with list of ASNs, that would be all or most of these ASNs: 7018, 1299, 1239, 3320, 6453, 6461, 3356, 3549, 2914, 3257, 3491, 701, 6762, 3491. Can you get a top-level summary of LCs with GA values from that list, and whatever the corresponding thing would be for EC or WC? E.g. How many unique LC values are there that match 3320:* ? Maybe a table with ASN vs common LC count would help illustrate this. If the majority (or vast majority) are already using LCs, and many fewer are using WC/EC, this definitely should tilt the argument towards LCs. Any of these networks which is using LCs extensively will very likely to be unwilling to use anything other than a WKLC (and this use of LCs was to a significant degree the result of requests from operators that use LCs to do it with LCs.) Brian ___ 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
There may be a knob that AS operators have for permitting transitivity, but we need to look at measurements to understand whether or not operators actually allow transitivity to EC and LC. NIST BGP measurements (thanks to my colleague Lilia Hannachi) were shared on the GROW list in May 2020: https://mailarchive.ietf.org/arch/msg/grow/JPD1-hhSvVXIZbUlNQ_1hmzD6IA/ A portion is copied below. The AS path length (# unique ASes) distributions for BGP updates with Communities (Regular, Large, and Extended) are shown here. It is evident that both LC and EC propagate multiple AS hops. Mass stripping of LC or EC at the first hop is not evident. The peak happens at AS path length 4 or 5 and that is good. That is the behavior that is helpful for route leak solution. The solution can still function even if some ASes strip. We can do some more detailed studies if needed. * RIPE-RIS: Community ANALYSIS (Collector : rrc03 From 2020-04-30 00:00 To 2020-04-30 00:55) * # Updates = 1075583 (Total) # (Regular) COMMUNITY = 859239 (79.89%) AS path length distribution =1: 170 (0.02%)2: 44803 (5.21%)3: 141072 (16.42%)4: 276271 (32.15%)5: 238325 (27.74%)6: 114158 (13.29%)7: 31365 (3.65%)8: 9018 (1.05%)9: 2690 (0.31%)10: 811 (0.09%)11: 358 (0.04%)12: 169 (0.02%)13: 22 (0%)14: 7 (0%) # LARGE_COMMUNITY = 152818 (14.21%) AS path length distribution =2: 5655 (3.7%)3: 17205 (11.26%)4: 54372 (35.58%)5: 45492 (29.77%)6: 22065 (14.44%)7: 6422 (4.2%) 8: 1068 (0.7%)9: 397 (0.26%)10: 71 (0.05%)11: 35 (0.02%)12: 26 (0.02%)13: 6 (0%)14: 4 (0%) # EXTENDED COMMUNITIES = 44606 (4.15%) AS path length distribution =2: 2269 (5.09%)3: 7435 (16.67%)4: 17657 (39.58%)5: 11600 (26.01%)6: 3967 (8.89%)7: 1221 (2.74%)8: 371 (0.83%)9: 57 (0.13%)10: 19 (0.04%)11: 8 (0.02%)12: 1 (0%) 13: 1 (0%) * Sriram ___ 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 Thu, Apr 1, 2021 at 6:11 AM Jeffrey Haas wrote:
> [Note, commenting as an individual contributor...]
>
> On Wed, Mar 31, 2021 at 03:10:08PM -0700, Brian Dickson wrote:
> > On Wed, Mar 31, 2021 at 7:57 AM Sriram, Kotikalapudi (Fed) <
> > kotikalapudi.sri...@nist.gov> wrote:
> > > 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 issue being faced here for WKLC is a few related items:
> - There needs to be some number of global admin (AS) reserved for generic
> use.
> - Since this was not done at the time the feature was shipped, there is no
> support in anyone's code to treat subsequently allocated ranges as
> "special".
>
This is correct. However, I am making the claim that lack of special
handling in anyone's code is NOT a blocker to use by operators.
Specifically, the proposed route-leak-detection-mitigation LC range
(assuming a very small number of fixed GA values) would be able
to be used by operators for arbitrary LC matching, which would be
sufficient to implement the detection/mitigation mechanisms.
While code would facilitate automatically doing the mitigation stuff, it is
not the only way mitigation can be achieved.
Having GA values assigned for this is necessary. Having code is not
necessary, but would be desirable (and should be a long-term goal).
The code side of things is true regardless of mechanism used, BTW -- it
could be LC, EC, WC, new attribute, or anything like that.
>
> The two larger criticisms of the WKLC draft to date is that it wanted a LOT
> of the AS space to be used, and that its transitivity functionality would
> not fit well into an incremental deployment of the feature. If the
> transitivity requirements are removed and the space is narrowed, that at
> least moves it closer to existing community operational practices. E.g. a
> single AS allocated for the purpose that leaves two unstructured fields, or
> a small number of ASes.
>
> This then would require implementations that want to treat the new
> well-known fields as "special" to have code to do so. So, we're already
> looking at some level of new code.
>
It is not necessary that this be done in code.
In fact, that is the precise motivation for using LC: no code is strictly
required.
Existing code for matching LC values is sufficient for operators to both
mark prefixes, and match LC values for implementing policy.
E.g. In vendor-agnostic pseudo-code:
IF(PEER_GROUP == MY_CUSTOMER && LC.GA == TBD1 && LC.VALUE1 == TBD2) THEN
DROP # Customer is sending us a marked prefix -- marked prefixes can only
be sent provider->customer
IF(PEER_GROUP == MY_PEER || PEER_GROUP == MY_TRANSIT) THEN ADD LC{LC.GA =
TBD1, LC.VALUE1 = TBD2, LC.VALUE2 = MY_ASN}
>
> Absent that new code, what we have is generic policy, along with the
> implementation's normal propagation behavior - which is behind a knob for
> some implementations.
>
This is correct.
>
> > 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*.
>
> If the state can fit into an extended community, that similarly can be done
> NOW. A significant portion of the extended community space is available on
> first-come, first-serve basis.
>
>
> https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml
>
> But it doesn't change the above issues.
>
> > 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
Re: [GROW] Choice of Large vs. Extended Community for Route Leaks Solution
Brian, >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 should have clarified. I am not opposed to staying on course with a WKLC based solution. I only thought transitivity readily came with Transitive Extended Community. Your proposal about one or a very small number of WKLC GA values seems fine and it is consistent with Sue’s advice. Please see my next post (in this thread) which is about transitivity measurements of EC and LC that should be helpful in this discussion. Sriram From: Brian Dickson Sent: Wednesday, March 31, 2021 6:10 PM To: Sriram, Kotikalapudi (Fed) Cc: Susan Hares; i...@ietf.org; draft-heitz-idr-w...@ietf.org; grow@ietf.org; a.e.azi...@gmail.com Subject: Re: Choice of Large vs. Extended Community for Route Leaks Solution On Wed, Mar 31, 2021 at 7:57 AM Sriram, Kotikalapudi (Fed) mailto: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). [Brian] Sorry to argue in public, but I disagree very strongly on the second part here. [Brian] We would like to continue proceeding with use of a LC range for implementation, using a single (or small number) of Global Administrator values. [Brian] 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. [Brian] 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*. [Brian] 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. [Brian] 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. [Brian] 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. [Brian] 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 ___ 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
[Note, commenting as an individual contributor...] On Wed, Mar 31, 2021 at 03:10:08PM -0700, Brian Dickson wrote: > On Wed, Mar 31, 2021 at 7:57 AM Sriram, Kotikalapudi (Fed) < > kotikalapudi.sri...@nist.gov> wrote: > > 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 issue being faced here for WKLC is a few related items: - There needs to be some number of global admin (AS) reserved for generic use. - Since this was not done at the time the feature was shipped, there is no support in anyone's code to treat subsequently allocated ranges as "special". The two larger criticisms of the WKLC draft to date is that it wanted a LOT of the AS space to be used, and that its transitivity functionality would not fit well into an incremental deployment of the feature. If the transitivity requirements are removed and the space is narrowed, that at least moves it closer to existing community operational practices. E.g. a single AS allocated for the purpose that leaves two unstructured fields, or a small number of ASes. This then would require implementations that want to treat the new well-known fields as "special" to have code to do so. So, we're already looking at some level of new code. Absent that new code, what we have is generic policy, along with the implementation's normal propagation behavior - which is behind a knob for some implementations. > 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*. If the state can fit into an extended community, that similarly can be done NOW. A significant portion of the extended community space is available on first-come, first-serve basis. https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml But it doesn't change the above issues. > 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. I question your conclusion. The desire is to have an attribute that is used for route leak mitigation purposes. This thread illustrates that it's very easy for such a control community in any flavor (regular, extended, large) to be stripped because the service provider hasn't proactively acted to permit it. Does this really solve the problem? -- Jeff ___ 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
[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
