RE: Size of CR in CRH

"Wang, Weibin (NSB - CN/Shanghai)" <weibin.wang@nokia-sbell.com> Wed, 20 May 2020 05:10 UTC

Return-Path: <weibin.wang@nokia-sbell.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 C45943A3A7A for <ipv6@ietfa.amsl.com>; Tue, 19 May 2020 22:10:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.106
X-Spam-Level:
X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 jcnZ8Wss1DqQ for <ipv6@ietfa.amsl.com>; Tue, 19 May 2020 22:10:20 -0700 (PDT)
Received: from CNSHJSMIN03.NOKIA-SBELL.COM (unknown [116.246.26.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA953A11BA for <6man@ietf.org>; Tue, 19 May 2020 22:10:18 -0700 (PDT)
X-AuditID: ac189297-fb9ff70000005564-77-5ec4bba19767
Received: from CNSHPPEXCH1601.nsn-intra.net (Unknown_Domain [135.251.51.101]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by CNSHJSMIN03.NOKIA-SBELL.COM (Symantec Messaging Gateway) with SMTP id EB.FC.21860.1ABB4CE5; Wed, 20 May 2020 13:09:53 +0800 (HKT)
Received: from CNSHPPEXCH1605.nsn-intra.net (135.251.51.105) by CNSHPPEXCH1601.nsn-intra.net (135.251.51.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Wed, 20 May 2020 13:09:54 +0800
Received: from CNSHPPEXCH1605.nsn-intra.net ([135.251.51.105]) by CNSHPPEXCH1605.nsn-intra.net ([135.251.51.105]) with mapi id 15.01.1847.007; Wed, 20 May 2020 13:09:54 +0800
From: "Wang, Weibin (NSB - CN/Shanghai)" <weibin.wang@nokia-sbell.com>
To: Tom Herbert <tom@herbertland.com>, "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
CC: 6man <6man@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
Subject: RE: Size of CR in CRH
Thread-Topic: Size of CR in CRH
Thread-Index: AQHWLWlZJuUe5H0OIki5CT6IpLNV6aiuQR+AgAAf0YCAAI/9gIAADTOAgAFkjkA=
Date: Wed, 20 May 2020 05:09:54 +0000
Message-ID: <df6ed4d1586e41a7ae9e310d62355f46@nokia-sbell.com>
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> <CALx6S36vj3WiN1uugP0DKJ-QyUQHiRFs=L-f_6jYedSsmS7RrQ@mail.gmail.com>
In-Reply-To: <CALx6S36vj3WiN1uugP0DKJ-QyUQHiRFs=L-f_6jYedSsmS7RrQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.251.51.115]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsXS/ts4VXfh7iNxBt3bbSxWrrjLZLH1/T42 i/OnprBYXL70iNmBxeP3wTfMHjtn3WX36J07jdVjyZKfTAEsUVw2Kak5mWWpRfp2CVwZj67/ Yy94sJCxYnX/S+YGxjNzGbsYOTkkBEwk5uz8DGRzcQgJHGKSWDTzBQuE85dR4tiDLWwgVUIC mxglHnzkALHZBNwkJm3bBRYXEYiWmLfvJzOIzSxgLfF14w8mEFtYQE6i98dXVogaeYnFZ25C 2X4S06/0sIDYLAKqEsc2nwWr5xWwk1g79QQrxOKPrBJLF00FG8opECjx+HUjO4jNKCAm8f3U GiaIZeISt57MZ4J4QUBiyZ7zzBC2qMTLx/+ABnEA2UoSfRuYQExmAU2J9bv0IToVJaZ0P2SH WCsocXLmE5YJjGKzkAydhdAxC0nHLCQdCxhZVjFKO/sFe3gF+3r6GRjr+fl7ezrqBju5+vjo Ofv7bmIERt0aiUnTdzA+n/VB7xAjEwfjIUYJDmYlEd4JLw7FCfGmJFZWpRblxxeV5qQWH2KU 5mBREudNe38wTkggPbEkNTs1tSC1CCbLxMEp1cCUKyjYrfZ7RkS0x/NnB7Iqnnz5+lPwxKYp XiK8gtt+M4R6tHw58qJe6PgZzxWHEj+ZBn0WkrxoutF4U5TJ/XN+rZGhG1+y9v2MmvZ69yT/ 9a4zptYmvntmV23632fyuw4u3XPlh+ZsWPZxVfGC8g2WL2Qead+vftW/iGvPg66TjJrvFvgc XVZpv6zCTz1j26vpUexKRfcU62znLa+csCsx6aHn6XPbz74U19fZsGbL44nfK1fOn/fcyO7J 1u0M3UV3mK2Kmfd+m+Sfn5oj9Ofsi2u8TWtc06MFtHtDU5TPXD642ctyFWel8fOCA1dtD/13 7bpqcmHh3fOP+pKqXijw3Ogv7/i33VU1+4vuf9d5AUosxRmJhlrMRcWJACcG4j8pAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/h68kXeRqXpecKvnXWZaP8Er1uDA>
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: Wed, 20 May 2020 05:10:27 -0000

As srv6 is deployed within a limited domain, however, the ipv6 address of 16 bytes as SRv6 SID has large redundancy information among all SIDs within limited domain deployed by srv6. In fact, 64 bits length is enough for encoding all kind of SIDs in any limited domain for deploying srv6.
 So I think the SID block may use a unified /64 prefix within each srv6 domain, all SIDs for each node regardless of topology SID or service SID within SRv6 domain should be assigned from next 4 bytes from the same /64 srv6 block, next-next 4 byte may be considered as Argument. 
After that, in srv6 domain, the left-most 64 bits of DA field of packet as SID block keep unchanged when packet passing through srv6 domain, only copy right-most 64 bits at SRv6 endpoint from modified-SRH which only include 64 bits for each length-reduced-SID, exclude encoding SID block prefix information in SRH. Of course it still is compatible all existing srv6 control plane extension draft, that is to say complete 128 bits length SID is kept at control plane operation, and no mapping mechanism.  But we can get 50% reduced size in SRH, however, we can still keep the simple forwarding procedure as rfc8754 in forwarding plane. It May be a compromise between SRH size and complex extent of forwarding procedure.


Cheers!

Wang Weibin

-----Original Message-----
From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Tom Herbert
Sent: 2020年5月19日 23:10
To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
Cc: 6man <6man@ietf.org>; Bob Hinden <bob.hinden@gmail.com>
Subject: Re: Size of CR in CRH

On Tue, May 19, 2020 at 7:23 AM Templin (US), Fred L <Fred.L.Templin@boeing.com> 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.
>
Another possibility is identifier/locator split. For instance, all the physical devices in many networks are assigned their own /64. In such cases the routing header can just carry 64 bit locators and no special mapping or control plane other than standard routing is needed.

Tom
> 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
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------