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

Robert Raszuk <robert@raszuk.net> Wed, 31 March 2021 13:40 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E343A28DF for <idr@ietfa.amsl.com>; Wed, 31 Mar 2021 06:40:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bouc-_SKOSjf for <idr@ietfa.amsl.com>; Wed, 31 Mar 2021 06:40:05 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68ADB3A28D9 for <idr@ietf.org>; Wed, 31 Mar 2021 06:40:04 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id u20so23842086lja.13 for <idr@ietf.org>; Wed, 31 Mar 2021 06:40:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dS49MdU7EpG1HU6ebK5woHNvbna8SpYC4HPk8OZCw5w=; b=RvYK5XJmYQtrj5GysqKT+FUCSE3hM8+gm1zjpu3ebsoL3USTNY16revd8Ch1EmS6Ze vQga8X6XnjU+5HuIulDA/AaSBCAF1tpSoOemu5A/gfd3IKFfb8yHB6Sx3NXUlufzcFiZ GhgsGZih3nGefQcn7ceLgfO4XGrj/q1mgViHVM3edQguAhSWs83PkEDxB01nd00D0/Sd 7I6y35HQ04EXVS7c/DHntJSk9pVi8A6gQss7IHnIc9B6X1eI02Pot1ji45JiN9e+Rb8+ pA0l0q4dijSFD+9c/xgFngGiQPF6RwYdN6WN44ssxaE4+Il51f2FHswzJPStK6WfoqA3 d1Mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dS49MdU7EpG1HU6ebK5woHNvbna8SpYC4HPk8OZCw5w=; b=V9vS+iXVLXXYA7InbE4IX4fSjTj5nxpCS/JmG6mHeONmK2KmTmW8siYnFmTKesdBRY 9mFvFa17w1HgUf0AJwhFvShrW1vmGA8RFybRYhltIArB9WuM3kQR9SzTcB31dz5M6NNI i2tUyBuc5DO4Gqbs6JTFJkcsNk3RewEyx1kJ692wwWavR7GqOUw0gE2icy94zLwTJCO4 ARz95DmyOn4BaNnS+5q1mz2T4unVAy2q4Fu9Fri9Cg9xGkD//etI3DVNzzae2yFitTdg a7e6vkPCIPzOfSnvR09+d6vazn/dICEuNC/nrKoYzml+OQ+cp4HcDIR5c4ChhJRAZtMn 22vg==
X-Gm-Message-State: AOAM533xAad9zkZrt5t3BGz84Gq/EAoc5VDfIy3J4IDMWtkRx5j/h8F9 3/o6ppQgdbPu/R7yvg/LjGr0chc8KU3tvAIYjEuj+jw+sCAUNDfs
X-Google-Smtp-Source: ABdhPJy+9sO4I7sMqps0bFy5V4zxPPJTrCZ1PhFrqn/rBBuNuZjfavwB8sEi0S4tbKeJ6Xx64M3G4SvME6m7gfqEMjM=
X-Received: by 2002:a2e:300d:: with SMTP id w13mr2199993ljw.199.1617198002331; Wed, 31 Mar 2021 06:40:02 -0700 (PDT)
MIME-Version: 1.0
References: <BYAPR11MB3207CF86CF2FBD56CA3EAD66C0919@BYAPR11MB3207.namprd11.prod.outlook.com> <CBFDE565-E501-4344-BF6C-53A541D50391@tsinghua.org.cn> <012b01d7170f$7ec90310$7c5b0930$@tsinghua.org.cn> <BYAPR11MB3207D4E973EE9ED170687E1EC06F9@BYAPR11MB3207.namprd11.prod.outlook.com> <015601d7171a$036be470$0a43ad50$@tsinghua.org.cn> <CAH1iCiqy3uu0SF2i9TyTRwCdt2d2Ud9+nUCtRG+vc2E-gwfLPQ@mail.gmail.com> <018a01d72274$bdeb63b0$39c22b10$@ndzh.com> <CAH1iCiqycXf7QJ7PuYQ7E8nJjdXpjcta_z39xOfdLsar3cAOJA@mail.gmail.com> <BYAPR11MB3207FF17C2AA82960EEFDC43C07D9@BYAPR11MB3207.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB3207FF17C2AA82960EEFDC43C07D9@BYAPR11MB3207.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 31 Mar 2021 15:39:51 +0200
Message-ID: <CAOj+MMGQnesamiuDFWYMWLxdt-EbceW3tCgt+gFS7m0svNKJJQ@mail.gmail.com>
To: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>
Cc: IETF IDR <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000075f89505bed540bb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Mcx_18wzxRCzfczgt57PocBReYw>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Mar 2021 13:40:11 -0000

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=
40cisco.com@dmarc.ietf.org> 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 <idr-bounces@ietf.org> *On Behalf Of * Brian Dickson
> *Sent:* Friday, March 26, 2021 12:42 PM
> *To:* Susan Hares <shares@ndzh.com>
> *Cc:* IETF IDR <idr@ietf.org>
> *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 <shares@ndzh.com> 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:idr-bounces@ietf.org] *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 <wangaijun@tsinghua.org.cn>
> wrote:
>
> Hi, Jakob:
>
>
>
> *From:* Jakob Heitz (jheitz) <jheitz@cisco.com>
> *Sent:* Friday, March 12, 2021 3:45 PM
> *To:* Aijun Wang <wangaijun@tsinghua.org.cn>
> *Cc:* idr@ietf.org
> *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 <wangaijun@tsinghua.org.cn>
> *Sent:* Thursday, March 11, 2021 11:16 PM
> *To:* Jakob Heitz (jheitz) <jheitz@cisco.com>
> *Cc:* idr@ietf.org
> *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:* idr-bounces@ietf.org <idr-bounces@ietf.org> *On Behalf Of *Aijun
> Wang
> *Sent:* Wednesday, March 10, 2021 9:38 PM
> *To:* Jakob Heitz (jheitz) <jheitz@cisco.com>
> *Cc:* idr@ietf.org
> *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) <jheitz@cisco.com> 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 <wangaijun@tsinghua.org.cn>
> *Sent:* Wednesday, March 10, 2021 12:11 AM
> *To:* Jakob Heitz (jheitz) <jheitz@cisco.com>om>; 'Susan Hares' <
> shares@ndzh.com>gt;; idr@ietf.org
> *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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>