Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

[Robert Raszuk <[e-mail]>]

Hey Jakob,

>   They belong in operator code, which is route-policy/route-map.

We clearly have different opinions on this part.

You keep stating that all route-policy must be typed by operator.

I am saying route-policy can be typed by operators from atomic match and
set primitives or route-policy can be smart enough to understand some
predefined policies. Especially if those are predefined in the RFCs. Think
of it in terms of pre-made policy templates like objects. They can be
enabled by default or disabled and enabled on a per needed/expected basis.

That way you do not need to write your policy each time from scratch :) Let
the router's vendor help you ...

I bring it here as that is also I think your key opposition to implementing
wide communities which can easily accommodate by design all requests
mentioned in this thread so far.

Best,
Robert.


On Wed, Mar 31, 2021 at 1:36 AM Jakob Heitz (jheitz) <jheitz=
[e-mail]> wrote:

> Best chance for Sriram is to do it with a new attribute.
>
>
>
> Community fields semantics do not belong in router code.
>
> They belong in operator code, which is route-policy/route-map.
>
> As soon as you define any structure into the community,
>
> then the semantics must be interpreted in router code.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Idr <[e-mail]> *On Behalf Of * Brian Dickson
> *Sent:* Friday, March 26, 2021 12:42 PM
> *To:* Susan Hares <[e-mail]>
> *Cc:* IETF IDR <[e-mail]>
> *Subject:* Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to
> 3/23)
>
>
>
>
>
>
>
> On Fri, Mar 26, 2021 at 12:18 PM Susan Hares <[e-mail]> wrote:
>
> Brian:
>
>
>
> <WG chair hat on>
>
> This brief justification for the ASN space even for 4-byte AS is not
> sufficient.   A separate draft will need to specify why so much ASN space
> that is managed by IANA.
>
>
>
> In the original work with route-leaks, John Scudder and I agreed to help
> the route-leaks folks obtain 2-8 ASNs specifically for the route leaks.
> Modifying your grow draft will obtain approval for a small amount of
> special ASNs.   I have discussed your need with IANA so that we had a sense
> of whether it would be approved.
>
>
>
> Asking for 1/64 of the address space requires substantial justification as
> it significantly limits the future uses of 4 byte-AS.
>
>
>
> The IDR WG allotted private ASN space for uses within an AS (or a
> Confederation AS) that spans multiple uses.   If you can make use of this
> space + 2-8 AS, your proposal can go forward.  If not, a separate proposal
> will be needed to justify that amount of address space.
>
>
>
>
>
> Would a request for reserving 255 ASNs for WKLC and establishing an WKLC
> registry (which would maintain parity with the original WKC reservation) be
> a reasonable compromise?
> Our GROW draft would then request something on the order of 2-4 of those
> values for the needs of the route-leaks draft.
>
>
>
> Thanks for your consideration.
>
>
>
> Brian
>
> (The only hats I wear are the ones to keep the sun out of my eyes and off
> my head. :-) )
>
>
>
> Thank you for being clear in this discussion with Aijun.
>
>
>
> Sue
>
> <WG Chair hat off>
>
>
>
>
>
> *From:* Idr [mailto:[e-mail]] *On Behalf Of *Brian Dickson
> *Sent:* Friday, March 12, 2021 1:14 PM
> *To:* Aijun Wang
> *Cc:* IETF IDR
> *Subject:* Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to
> 3/23)
>
>
>
>
>
>
>
> On Fri, Mar 12, 2021 at 12:31 AM Aijun Wang <[e-mail]>
> wrote:
>
> Hi, Jakob:
>
>
>
> *From:* Jakob Heitz (jheitz) <[e-mail]>
> *Sent:* Friday, March 12, 2021 3:45 PM
> *To:* Aijun Wang <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to
> 3/23)
>
>
>
> 1.      It is small, not huge as explained in the draft.
>
> *[WAJ] When compared to the 22 well-known community, “67,108,864 AS
> numbers” is too large.  I am worrying the unnecessary reservation may
> prevent the allocation of the unallocated AS-number for other purposes.*
>
>
>
> The range of reserved ASNs occupies two bits of the upper 8 bits, plus the
> entirety of the the next 24 bits in its range.
>
> This represents a single value from the 6-bit portion of the ASN space, or
> exactly 1/64 of the 32-bit ASN space.
>
> Given that the current usage for ASNs is 2^16 for the 16-bit ASNs, plus
> less than 7 bits out of the upper 16 bit range, that is roughly 64/65536 or
> about 1/1000.
>
> This still leaves well over 31/32 of the potential ASN space, so I believe
> your worry is unjustified.
>
>
>
> 2. It got updated and I missed it when I updated my draft. Thanks for
> catching it.
>
> 3. I don't understand your question. Can you expand?
>
> *[WAJ] why not take the approach directly as that descried in  *
> https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-04.
> ?
>
> *That is to say, for each potential well-known large community, reserve
> one value for the “Global Administrator” part of the large community, and
> defined the associated data for the other two local parts. Transitive or
> non-transitive can be defined accordingly. *
>
> *Currently, you define “WKLC ID” as the large community type. From the
> definition of large community(RFC8092), the “Global Administrator” part
> will be divided into 256 groups, each group will have 2^16 number, that is
> 2^16 well-known large communities? *
>
> *I know you want to leave some field to the data part, but this arises
> some confusion when your proposed encoding is different from the original
> definition of RFC8092.*
>
>
>
> The logic for this is as follows:
>
> The initial use case is to establish a structured value of TBD1:TBD2:ASN
> for the route-leak-detection-mitigation (as that draft explains).
>
> The TBD2 is a single value out of a 32-bit range which will be in its own
> (new) registry. Having a registry allows for future uses in the context of
> TBD1, allowing new kinds of LC's in this bigger registered range.
>
>
>
> However, the router implementations, for the most part, permit filtering
> of LCs on the basis of 3 32-bit values, where either literal values or
> wildcards can be used.
>
> Having the elements be aligned on the 32-bit boundary, and having TBD1 and
> TBD2 be fixed values, permits LC matching using a patterns of either
> TBD1:TBD2:* (wild-card), or TBD1:TBD2:ASN (explicit ASN match).
>
> In other words, this structure choice is forced by router implementations,
> and really not appropriate to second-guess. It isn't up for negotiation, as
> this is a necessary requirement for the first use case.
>
>
>
> BTW: Both of these patterns (fixed single value and wild-card of lower
> 32-bit value) are required to implement the GROW draft you referenced.
>
>
>
> Having said that, this is the first out of up to 255 WKLCs, and the
> maximum benefit to other potential uses for WKLC is achieved by making the
> maximum (reasonable) number of octets available for those other WKLCs,
> specifically 10 octets of undefined structure.
>
>
>
> In particular, it is possible that other WKLCs require two ASN data values
> in their encoding (such as a source ASN and a destination ASN), and
> additional values (single bits or ranges of values) beyond that. Limiting
> the WKLC to having only single Global Administrator values and 8 octets of
> data, would be insufficient in that case.
>
>
>
> This would require re-design of WKLCs at a later date, and it may not be
> possible due to existing usage or reservations of WKLCs.
>
>
>
> By providing more octets to EACH WKLC, this problem is prevented. Making
> data allocations on power-of-two boundaries at the highest order is
> necessary up front. Attempting to expand ranges after allocations is
> possible, but may not be compatible with the power-of-two alignment
> required by future use cases of WKLC.
>
>
>
> You cannot aggregate that which was not initially allocated in a fashion
> suitable for aggregation. This was one major outcome of the IP allocation
> strategies prior to CIDR addressing for IPv4 address space. We would do
> well to learn from the mistakes of others, particularly when those mistakes
> were effectively repeated in the ASN space already (16 bits to 32 bits,
> because the initial assumption was 16 bits would be sufficient).
>
>
>
> So, in summary, the reservation of the range of ASNs is specifically to
> permit applying structure to the LC values within that range.
>
> The original LC definition is only applicable to "actual" ASNs as Global
> Administrator. RFC8092 says only "intended", and that the value "SHOULD" be
> an ASN.
>
> This is a new use case, and is the reason RFCs use "SHOULD" instead of
> "MUST".
>
> (What RFC8092 really says is, LCs where the Global Administrator value
> corresponds to an actual assigned ASN, are reserved exclusively for the
> operator of that ASN.)
>
> Since this proposal sets aside a range of ASNs as a group, the structure
> of LCs covering that range can be redefined accordingly, as long as that
> redefinition is scoped to that range of ASNs.
>
> This is EXACTLY what this WKLC proposal is doing, and nothing more.
>
> The other draft is for the use of the first assigned WKLC values (single
> ID plus the Transitive Bit values).
>
>
>
> Hope this clarifies the usage and compatibility with other RFCs.
>
>
>
> Brian
>
>
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Aijun Wang <[e-mail]>
> *Sent:* Thursday, March 11, 2021 11:16 PM
> *To:* Jakob Heitz (jheitz) <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to
> 3/23)
>
>
>
> Hi, Jakob:
>
>
>
> More questions for your draft:
>
> 1.     Do we need to reserve such huge range(4093640704 (0xF4000000) to 4160749567 (0xF7FFFFFF) as you described in https://datatracker.ietf.org/doc/html/draft-heitz-idr-wklc-02#section-6 for the countable well-known large communities?
>
> 2.     There is some inaccurate description for the current reserved AS number space in https://datatracker.ietf.org/doc/html/draft-heitz-idr-wklc-02#section-4.  You can check it at https://www.iana.org/assignments/as-numbers/as-numbers.xhtml. The unallocated AS range is 401309-4199999999, not at described in your draft “The range of AS numbers currently unallocated by IANA is 399,261 to 4,199,999,999.”
>
> 3.     What’s the necessary to group such WKLC via the WKLC ID?
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* [e-mail] <[e-mail]> *On Behalf Of *Aijun
> Wang
> *Sent:* Wednesday, March 10, 2021 9:38 PM
> *To:* Jakob Heitz (jheitz) <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to
> 3/23)
>
>
>
> Yes, if we reserve some 4-bytes AS range, then your concerns will not
> happen.
>
> The well-known large community need just be allocated from this reserved
> range. That’s all.
>
> Do we need other definitions in your draft then?
>
> Aijun Wang
>
> China Telecom
>
>
>
> On Mar 10, 2021, at 21:18, Jakob Heitz (jheitz) <[e-mail]> wrote:
>
> 
>
> Consider if there is a real AS that uses 4,093,640,704 as its ASN.
>
> And if this AS were to send a large community of its own.
>
> It would put its ASN into the Global Administrator field of the LC.
>
> This ASN is 11110100000000000000000000000000 in binary.
>
> Then another AS sends a WKLC with WKLC ID 0, Transitivity 0 and Data 1 = 0.
>
> This has the same bit pattern.
>
> To avoid the clash, we need to reserve the ASNs that would clash.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Aijun Wang <[e-mail]>
> *Sent:* Wednesday, March 10, 2021 12:11 AM
> *To:* Jakob Heitz (jheitz) <[e-mail]>; 'Susan Hares' <
> [e-mail]>; [e-mail]
> *Subject:* RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to
> 3/23)
>
>
>
> And, what the reason to assign the “111101”value in the first 6bit your
> encoding? It is not conformed to general definition of large community, in
> which the first 4-bytes is to identify the Global Administrator.
>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>