Re: Size of CR in CRH

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 19 May 2020 21:20 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAFE3A0BBF for <ipv6@ietfa.amsl.com>; Tue, 19 May 2020 14:20:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=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=gmail.com
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 SxtSqe0o5lJI for <ipv6@ietfa.amsl.com>; Tue, 19 May 2020 14:20:14 -0700 (PDT)
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 9E6BE3A0AD9 for <6man@ietf.org>; Tue, 19 May 2020 14:20:14 -0700 (PDT)
Received: by mail-pj1-x102c.google.com with SMTP id z15so1567937pjb.0 for <6man@ietf.org>; Tue, 19 May 2020 14:20:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=W1QHXU+buwEpcwqu0yCFq/UZviZwHMiqjqnaTTWtwPE=; b=oTBFga7XNea+eD1ArhkqZOnEZUNTC9uqSehU+PMvTOOKQpL+tbuei/lJdph7pioNCK 7LNqCnQ5Wto4N6y7eBAa3+kjA56SC877SIA+o1AlNDO7TFmtYJDmDqHDSiQnpfdQbrjK m2lYSDa0r/zNC8I7ea1Q3M69b85P7GIr+UMjgnA74cnUaFwnn8/AAIOmT/ICtgLtLltA 6sQxlhbQiP+DPIsKpKulw6g156tZqA25o3HZMulpEXkeJrlM3JWVMXfzHKDYSLH56KXj GaIPHad6C/BBOcEdjbBWU12omV96L8k6FAXzGuMGHsNhdpaEwNjxX2dVMGr8IBFX8Plo XkjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=W1QHXU+buwEpcwqu0yCFq/UZviZwHMiqjqnaTTWtwPE=; b=Y/v1sS4/Ceo+ha+4wm4uyy73WB61THJQn+Nb/YXw5rpmirmQeCSvaMhsYMxhOD2Cns 2oXAVIfngvU9TnGB/RIZo1WO24O4OqDKcuhZMptd1rAxDpDdyprA44Ee+LHnq78Jwwi3 duhAagQ07CETa3itjZU508p8X97e/5Qz8rLGE8MI+F6duyBLmuhvFH236uiaGT87eyoj qYKmTEBYVjqgItSUhCbwKIKAomXDc4NNIkCy9P5DMVTsmSOt5hQMYugN5rL6QMHd1rrS Og/Ww3dnYiy0+YBEaBubWpulCWgkvCtBcIYJF+l+9ez9R5cG0/tvOiGw7HU7hb8zJp9L dpCQ==
X-Gm-Message-State: AOAM5334O2kDQ7CQfWiH8fGE0gLR3g19dMkZu9CU9UC2wT0gkwhvK4Uj fd4tHuX4WscmjbzICjI2Z8/CgzjK
X-Google-Smtp-Source: ABdhPJye6QU+5cz54aguQIrYa2ToLtctNE1RbU6b71y/FLxgpDM1FgVWTEFmHFzM4vmORQgVuJAOpQ==
X-Received: by 2002:a17:90b:358c:: with SMTP id mm12mr1433534pjb.134.1589923213468; Tue, 19 May 2020 14:20:13 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id go1sm368662pjb.26.2020.05.19.14.20.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2020 14:20:12 -0700 (PDT)
Subject: Re: Size of CR in CRH
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, Bob Hinden <bob.hinden@gmail.com>
Cc: 6man <6man@ietf.org>
References: <DM6PR05MB6348E9AD1E088792C2F10BB4AEBF0@DM6PR05MB6348.namprd05.prod.outlook.com> <8CC3F837-B4D6-4570-AF2F-37041839F391@employees.org> <21E9A957-1A31-4A11-8E78-5F7E382866D4@juniper.net> <CAOj+MMEONA5OtWz9Y7pTt4WyVsb+7-_wEKPVryyHLncHG6ew6g@mail.gmail.com> <CALx6S35fPrnh6UtpPYmQ6Yew6D2QVMvYTdp0AaGr8jYhGNKk3A@mail.gmail.com> <CAOj+MMH0Q6ASmjPdmgNB2LHDhvCL2u2DLB9SBRLnJnCD3EbA4w@mail.gmail.com> <CAO42Z2wke4Lw44zdE0G9CJq3rXh69jsxjO5=RTcCv9EXdNOp5A@mail.gmail.com> <BC6A6354-BAB5-4CE0-ABEB-73B4C88E149A@gmail.com> <a2bb7b9df11949cc8a82184d8800bd32@boeing.com> <FC9DA088-287C-4653-843E-BBCB8A235CC7@gmail.com> <7824db15e87d4547ada0628891442049@boeing.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <07ba8503-cc68-3a03-1a87-6dba386e1730@gmail.com>
Date: Wed, 20 May 2020 09:20:07 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <7824db15e87d4547ada0628891442049@boeing.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/yZyhaN0xnwAXmUnmZxFYvIwV6fA>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 May 2020 21:20:17 -0000

On 20-May-20 02:22, Templin (US), Fred L wrote:
> Bob, my estimate of scale may have been a bit overblown; there are only 7 billion
> people on the planet so "countless billions" of routers may still be a long way off.
> That said, about a routing protocol I believe we can get what we need out of
> standard BGP as long as the routers don't move around very much.

But when they do move around quite a lot, and frequently go up and down, it seems to me that you are in the area that RPL was designed for, and everything is different from BGP.

   Brian
 
> Thanks - Fred
> 
>> -----Original Message-----
>> From: Bob Hinden [mailto:bob.hinden@gmail.com]
>> Sent: Monday, May 18, 2020 10:47 PM
>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
>> Cc: Bob Hinden <bob.hinden@gmail.com>; Mark Smith <markzzzsmith@gmail.com>; 6man <6man@ietf.org>
>> Subject: Re: Size of CR in CRH
>>
>> Fred,
>>
>>> On May 18, 2020, at 8:53 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
>>>
>>> Bob, I am interested in environments where there are potentially countless billions of
>>> routers. The mobile host is a 20th century archetype; the archetype for the 21st century
>>> is mobile *routers*. And yes, these can show up as hops in a source route.
>>
>> I think source routes will be the least of your problem with this.   For example, designing a routing protocol to work at this scale will be
>> a problem.
>>
>> Bob
>>
>>
>>>
>>> Thanks - Fred
>>>
>>>> -----Original Message-----
>>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden
>>>> Sent: Monday, May 18, 2020 4:08 PM
>>>> To: Mark Smith <markzzzsmith@gmail.com>
>>>> Cc: 6man <6man@ietf.org>; Bob Hinden <bob.hinden@gmail.com>
>>>> Subject: Size of CR in CRH
>>>>
>>>> [Was Adoption call criteria for CRH? [was: Re: CRH and RH0] ]
>>>>
>>>> Hi,
>>>>
>>>> With no hats on:
>>>>
>>>>> On May 18, 2020, at 2:37 PM, Mark Smith <markzzzsmith@gmail.com> wrote:
>>>>> I would prefer CR had a singe size of 24 bits, as that would seem to
>>>>> me to be the Goldilocks size for local network use (16 million
>>>>> values), and per RFC 5505, "Anything that can be configured can be
>>>>> misconfigured.".
>>>>>
>>>>> However I don't know enough about ASICs to judge whether or not 24
>>>>> bits could be acceptably accommodated for all cases, so I accept 2
>>>>> sizes, 16 and 32 bits.
>>>>
>>>> I also prefer a single size (and only one SR header definition).   If it’s 16-bits, that would allow 64K routers in one CRH domain
>> assuming
>>>> it needs to uniquely identify each router, if there is more than 64K routers, then it only needs to identify the routers that are
>> serving
>>>> as hops in the source route.
>>>>
>>>> As you note 24 bits is better, but may not align as well.   Or then 32-bits.
>>>>
>>>> Bob
>>>>
>>>>
>>>>>
>>>>>> *C* No mention what happens when node in the SID list is down ... modern networks do not tolerate outages required to signal
>> all
>>>> the way to the ingress to redo computation and start repair from there. This is BAD NETWORK DESIGN.
>>>>>>
>>>>>
>>>>> This problem exists with any source routing, and has existed for many
>>>>> decades in IPv6, IPv4, MPLS and Token Ring source routing. ICMPv6,
>>>>> routing protocol signalling, BFD, etc. are all existing solutions to
>>>>> this problem.
>>>>>
>>>>>> *D* Separation of destination actions into Destination Options Header. For some it may be a plus - for me this is minus.
>>>>>>
>>>>>
>>>>> RFC8200 compliance.
>>>>>
>>>>> Separating hop-by-hop and destination option processing is good design
>>>>> because forwarding needs to be as simple and as fast as possible.
>>>>>
>>>>> Complex packet handling should be left to End-hosts because they're
>>>>> only performing actions for themselves, so the cost of complex
>>>>> processing is limited to the end-host that is exclusively benefiting
>>>>> from it.
>>>>>
>>>>> Complex packet handing in the network spreads the complexity costs to
>>>>> all end-hosts attached to the network, even those that don't and may
>>>>> never benefit from it.
>>>>>
>>>>>> *E* Unlike say SRH RFC this draft does not even mention once that to impose CRH packets should be encapsulated.
>>>>>>
>>>>>
>>>>> While I think it is implicit in RFC8200, it probably should be
>>>>> explicitly mentioned with a reference to RFC 2473, which shows how to
>>>>> add new information through EHs to an existing packet via tunnel
>>>>> encapsulation.
>>>>>
>>>>> Regards,
>>>>> Mark.
>>>>>
>>>>>
>>>>>> Thx,
>>>>>> R.
>>>>>>
>>>>>> On Mon, May 18, 2020 at 4:26 PM Tom Herbert <tom@herbertland.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, May 13, 2020 at 1:12 PM Robert Raszuk <robert@raszuk.net> wrote:
>>>>>>>>
>>>>>>>> John,
>>>>>>>>
>>>>>>>> May I add one more perspective to this.
>>>>>>>>
>>>>>>>> 6man just standardized SRH. Why SRH content can not be filled by controller and used for the very same purpose as authors
>>>> intend to use CRH for ?
>>>>>>>>
>>>>>>>> Oh one may say there is no compression there ... If so I recommend to take a look at uSID and vSID proposals.
>>>>>>>>
>>>>>>> Hi Robert,
>>>>>>>
>>>>>>> I took a look at these proposals. It's very obvious that the format of CRH is significantly simpler than either of these and is
>> simpler
>>>> than SRH as well. Complexity in protocol format correlates to how amenable the protocol is to feaible implementation (in HW and
>> SW),
>>>> how well it can be secured, and how efficient in terms of wire overhead and processing overhead.
>>>>>>>
>>>>>>> It is interesting to note that figure Figure 3 in draft-decraene-spring-srv6-vlsid-03 would be identical to Figure 1 in draft-bonica-
>>>> 6man-comp-rtg-hdr-22 if the Last Entry, Flags, Tag, and TLVs fields were removed. Since these fields aren't used in the common
>> case,
>>>> they are easily compressed by simply removing them. So the material difference between the formats is how the length of SIDs is
>>>> determined. In CRH this is explicit in the routing type, there is one type for 16-bit SID format and one type for 32-bit format..
>> AFAICT in
>>>> vSID the SID length is more like a negotiated parameter that per destination address that uses the same routing type as SRH. While
>>>> the vSID method might be more flexible and allow arbitrary SID lengths, it leads to more complexity since the routing header can
>> no
>>>> longer be parsed without external information. For instance, if a management device snoops packets in the path it wouldn't be
>> able to
>>>> parse the SID list without participating in the protocol that distributes the length information. Similarly, if a legacy SRH receiver
>> receives
>>>> a vSID header it seems like it would parse it incorrectly.
>>>>>>>
>>>>>>> In any case, I don't see why the vSID and CRH proposals couldn't be unified or why SR wouldn't be able to use CRH to convey
>>>> compressed SIDs.
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>>> Is it in good interest of anyone deploying segment routing to have to deal with N different non interoperable headers ? Does
>> it
>>>> make anyone's life easier ?
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Robert.
>>>>>>>>
>>>>>>>> PS. So my own side observation lead me to believe it is not about "too early to ask for adoption" ... it is actually "way too late"
>>>>>>>>
>>>>>>>> On Wed, May 13, 2020 at 10:01 PM John Scudder <jgs=40juniper.net@dmarc.ietf.org> wrote:
>>>>>>>>>
>>>>>>>>> I’m a little confused about this conversation and I’d like to ask the chairs for clarification. My actual questions are at the end
>> of
>>>> this long(ish) message, and can be summarized as (1) does 6man require consent from SPRING before defining routing headers,
>> and
>>>> (2) what criteria are the chairs using to decide when an adoption call is OK?
>>>>>>>>>
>>>>>>>>> It seems to me there are at least two, only vaguely related, conversations going on. One of them is a debate about the
>>>> assertion that 6man can’t even consider taking up CRH unless SPRING approves it. The other is a more free-wheeling line of
>>>> questioning about “what is CRH for anyway”?
>>>>>>>>>
>>>>>>>>> I presume both of these relate to Ron’s request for an adoption call. Here’s what the minutes from the interim have:
>>>>>>>>>
>>>>>>>>>> Bob: Thank you Ron. I think it's too early for adoption call.
>>>>>>>>>>
>>>>>>>>>> Ron: What is needed to get to adoption call.
>>>>>>>>>>
>>>>>>>>>> Bob: I can't answer right now.
>>>>>>>>>>
>>>>>>>>>> Ron: Can I ask on list?
>>>>>>>>>>
>>>>>>>>>> Bob: OK.
>>>>>>>>>>
>>>>>>>>>> Ole: Related to what's going on in spring.
>>>>>>>>>
>>>>>>>>> Too bad we have no audio recording, but that’s not too far from my recollection. Anyway, I don’t think I’ve seen this
>> answered
>>>> on list yet, so I’m asking again.
>>>>>>>>>
>>>>>>>>> Regarding the SPRING-related process stuff:
>>>>>>>>>
>>>>>>>>> I have quite a bit of history with how SPRING was chartered; I was one of the original co-chairs and helped write the charter,
>>>> god help me. I can tell you for certain there was no intent that SPRING should have exclusive ownership of source routing in the
>> IETF,
>>>> the name isn’t a power-grab, it’s a clever backronym, as we do in the IETF. If one entity in the IETF were to take charge of all source
>>>> routing, that sounds more like a new area than a WG. But don’t take my word for it, go read the various iterations of the charter. As
>>>> anyone who’s looked at the Segment Routing document set can tell, Segment Routing is one, very specific, way of doing source
>>>> routing. As Ketan and others have pointed out, it’s a pile of architecture plus the bits and pieces to instantiate that architecture.
>> That is
>>>> fine, but the idea that merely because a technology might be used to instantiate part of that architecture, it’s owned by SPRING, is
>>>> overreach. Just because a sandwich is a filling between two pieces of starch, doesn’t mean every filling between two pieces of
>> starch
>>>> is a sandwich. [1]
>>>>>>>>>
>>>>>>>>> But at any rate, the question for the chairs is: do you think 6man needs SPRING’s permission in order to consider adopting
>>>> CRH? Does 6man need permission from SPRING for all routing headers, or just some, and if it’s just some, what characterizes
>> them?
>>>>>>>>>
>>>>>>>>> Regarding the more general “what is CRH for anyway” stuff:
>>>>>>>>>
>>>>>>>>> This seems to me to be exactly the kind of discussion one would normally have in the context of an adoption call. Why is it
>> not
>>>> being had in that context? To rewind back to the interim, if it’s still “too early for adoption call”, what has to happen for it not to be
>> too
>>>> early?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> —John
>>>>>>>>>
>>>>>>>>> [1] https://cuberule.com
>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>> IETF IPv6 working group mailing list
>>>>>>>>> ipv6@ietf.org
>>>>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>
>>>>>>>> --------------------------------------------------------------------
>>>>>>>> IETF IPv6 working group mailing list
>>>>>>>> ipv6@ietf.org
>>>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>> --------------------------------------------------------------------
>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list
>>>>>> ipv6@ietf.org
>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> --------------------------------------------------------------------
>>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>