Re: Size of CR in CRH
Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 22 May 2020 03:04 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 B75BD3A0E07 for <ipv6@ietfa.amsl.com>; Thu, 21 May 2020 20:04:45 -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 H8jqgCQlmCU4 for <ipv6@ietfa.amsl.com>; Thu, 21 May 2020 20:04:43 -0700 (PDT)
Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 993B23A0DF3 for <6man@ietf.org>; Thu, 21 May 2020 20:04:43 -0700 (PDT)
Received: by mail-pg1-x52d.google.com with SMTP id p30so4296528pgl.11 for <6man@ietf.org>; Thu, 21 May 2020 20:04:43 -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=Ywv6rZ/iV7yh8Z6TTcvyhg0zWkDs9J+axC/HrCMxjhQ=; b=coxs1xUmrZQ4/aJjly4j3pWbLpGRzlZjdmw8ZW9mxvU8zB7rnH5IT7D5hzx/HnvIMy LdYSUCnseejMrPJI2VmVUIZN1Ou7nMKbi9b5mfekrYVLFHAy8IefL1QCHi8M4Jm5sm3U bzbMLf6H46BNkvoG2gqY2h25wCbDk+1dssZ0FMfnGelUDsgXLg8U2ic0cSGOfx6xlp64 KXXIBkNOAat1pNw4/jmwQEikcQmqJQH0PCvBgMjRq94fAUiy6m1L1ocdlLfSSOO/tin2 q/6heUJ2Ye1LiMmvAQQ3Eyw9DLVpRky5uVVYg8ZkoAZXgGERhO83fRrJXu9gyWQkcYHS Gv9A==
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=Ywv6rZ/iV7yh8Z6TTcvyhg0zWkDs9J+axC/HrCMxjhQ=; b=ik8NI3cXCyFhlZG0rQ7MLU08Kb6kEBipuNYj+2l6spXNIKWRxM36KK7ZOL58Sim/D4 Sev+TSvGF+dNxAgMdW72RqohN1FLVbj4Ah04Rqxz3lrGchaBFgX9eLBQjEF8AWdldsLl hMY++Tb1896f0Yd86J2eGzkBWBogon9ZPEXp2x2IfdjegSR2tQG5fOOt+WxMlJU+99Am 5gnKylWA7GnogJwtuj1FQVi0cYNm8WMA+5DGLaj3z3Xeiy4NSxJjn98oeTZG3OhcKrOj I0yE5VJGAew2nsHDnKaXIWyvFhFYEFDfkmUKO02QtMWz4wiV625BjoElLDCanIchg1/i mIvA==
X-Gm-Message-State: AOAM532l7idQnR4Xuk2Pq5w7b5cAA587zPNIe8uAYRXb3rZjAt9Al7mZ KdU863LNPnJ8V/VKk73MMwA0eS2l
X-Google-Smtp-Source: ABdhPJwS4O0ZtzPNTO00k0BqQRuKfEl2ZuprJNhjAKDI3RaQNOE73LN0zG2Sl0/cEXGwDZ2oi6Ovyg==
X-Received: by 2002:a63:1103:: with SMTP id g3mr11862141pgl.206.1590116682349; Thu, 21 May 2020 20:04:42 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id 134sm4480803pfy.38.2020.05.21.20.04.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2020 20:04:41 -0700 (PDT)
Subject: Re: Size of CR in CRH
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Robert Raszuk <robert@raszuk.net>
Cc: 6man <6man@ietf.org>
References: <CAOj+MMFsy=dDciY=TMwSf75CZCr_i1Mfv6oUiPs5U6hT2Bq94w@mail.gmail.com> <DM6PR05MB6348D0DB381145F1A4C53450AEB70@DM6PR05MB6348.namprd05.prod.outlook.com> <CAOj+MMHT=TWqf=A71PhvCcrFggCQ=okRrP=sGaO4hrcbmsCvGw@mail.gmail.com> <CAOj+MMGYbw83c-T9GWCs_cLDWWbGi1dZ_Xfc8tS6TV6EfvWsDw@mail.gmail.com> <DM6PR05MB63484502B4CFCB745DFCED3EAEB70@DM6PR05MB6348.namprd05.prod.outlook.com> <CAOj+MMEfkenHmSLje62wNRw3OrxBzJJq_MwesozK-ABeLXbZ2Q@mail.gmail.com> <DM6PR05MB634807B4AAB6452B6FDA535CAEB70@DM6PR05MB6348.namprd05.prod.outlook.com> <CAOj+MMEX3qxQw0WHt3b69-KL5w+Ozufh_2eod-VO6Bt-ojSf9A@mail.gmail.com> <DM6PR05MB6348382D4496673BA96140C3AEB70@DM6PR05MB6348.namprd05.prod.outlook.com> <CAOj+MMFB3fYuYn5euzUzPpZbxr81eN5zfa2ATyHhC3RJbtch=A@mail.gmail.com> <DM6PR05MB634817EB3CB574C5A7D0BA77AEB70@DM6PR05MB6348.namprd05.prod.outlook.com> <CAOj+MMF9SsxSMXuVVQJmrQQGdsGN=RMeb2Kxu88+bjH__7r=Lg@mail.gmail.com> <05b32199-e282-f5e6-6ca8-fea5acb0101a@joelhalpern.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <9673ac60-f9a3-44c8-3c13-5f447302cfff@gmail.com>
Date: Fri, 22 May 2020 15:04:36 +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: <05b32199-e282-f5e6-6ca8-fea5acb0101a@joelhalpern.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/J2UVBYpU4qlCqDqL5PXZq3iyBaE>
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: Fri, 22 May 2020 03:04:46 -0000
Joel, On 22-May-20 12:21, Joel M. Halpern wrote: > Robert, local signifance has a very clear meaning in this space. We > understand it in MPLS. We understand it in SRv6. > And in neither case does it mean that nodes can make up any old label, > and use it any old way, without suitable communication / coordination. > > However, equally, the exact coordination depends upon the control > mechanism and indications one wants to use. For example, if local > labels always follow global labels which indicate their presence, then > sure, you can use almost any value. But if the disciple or pattern is > different, then different constraints apply. > > So just what are you trying to ask? I'm not sure what Robert's question is. Mine is something like this: If the local domain contains routers from vendor A, routers from vendor B, and a management system from C, what are the minimum rules about the label's format and semantics that must be followed to guarantee interoperability? In other words, C needs to be able to tell both A routers and B routers the same thing in order to set up their CRH-FIBs. A supplementary question is: Should those rules be specified in the basic CRH draft, or in a separate document? (I have a similar question about the SRH work, but it probably doesn't belong here.) Regards Brian > > Yours, > Joel > > On 5/21/2020 6:29 PM, Robert Raszuk wrote: >> Hi Ron, >> >> I don't think we need to go through a tutorial here what the FIB, >> CRH-FIB or LFIB is. >> >> I asked specific question on which you have not provided any answer: >> >> If I have part of the network non CRH aware and each node is free to >> allocate their own SID - as you are claiming SIDs are locally >> significant - how would the CRH look like in case of SID conflict >> between local node and remote node SID collision. >> >> Now rest of your answer is rather vague at best. And this is not just a >> detail. This is fundamental frame to the proposal we are discussing >> adoption of. >> >> Sure once document becomes a WG a collective brains can paint it well - >> but if it does not even have solid frames it may be a pretty hard task. >> >> Just my own little side input. Others may see it different way, >> >> Many thx, >> R. >> >> >> On Fri, May 22, 2020 at 12:22 AM Ron Bonica <rbonica@juniper.net >> <mailto:rbonica@juniper.net>> wrote: >> >> Robert,____ >> >> __ __ >> >> I think that you are confusing two data structures. The CRH-FIB is >> just that, a FIB. I contains enough information to resolve an >> incoming identifier to an IPv6 address and a forwarding method. Each >> node maintains a unique CRH-FIB and there is no requirement for >> nodes to share their CRH-FIBs with one another. The CRH-FIB lives on >> the forwarding plane and is an appropriate topic for 6man.____ >> >> __ __ >> >> Somewhere in the network, there is an entity constructs the CRH and >> the list that it contains. That entity needs access to another data >> structure, that includes a global view of each node’s CRH-FIB. That >> entity might be:____ >> >> __ __ >> >> * A human, manually constructing forwarding policy____ >> * A controller____ >> * Path computation software on a router.. ____ >> >> __ __ >> >> Ron____ >> >> __ __ >> >> __ __ >> >> __ __ >> >> Juniper Business Use Only____ >> >> *From:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>> >> *Sent:* Thursday, May 21, 2020 4:05 PM >> *To:* Ron Bonica <rbonica@juniper.net <mailto:rbonica@juniper.net>> >> *Cc:* 6man <6man@ietf.org <mailto:6man@ietf.org>> >> *Subject:* Re: Size of CR in CRH____ >> >> __ __ >> >> *[External Email. Be cautious of content]____* >> >> __ __ >> >> Hello Ron,____ >> >> __ __ >> >> > Why should it? It isn’t attached to link X->Y. So it couldn’t use >> that entry even if it had it. ____ >> >> __ __ >> >> This question I think exposes or uncovers (at least for me) the crux >> of your proposal ... perhaps even fatal one. ____ >> >> __ __ >> >> You are assuming that only locally allocated SIDs are in CRH-FIB - >> that is fatal assumption for bunch of reasons ... one swapping DA to >> some node N hops away. How are you going to accomplish that if such >> entries are not even in CRH-FIB ? ____ >> >> __ __ >> >> I guess it is very clear now why the other day you stated that "all >> nodes in the domain must support CRH". ____ >> >> __ __ >> >> What seems you are doing here ... and of course this is not written >> anywhere in any document ... so this is pure acceptance call >> guessing - is a forward referencing SIDs against the peers. ____ >> >> __ __ >> >> So on any node you are allocating SID per interface - >> strictly speaking per forwarding adjacency. Clearly you can not >> build such construct for remote nodes based on the above. ____ >> >> __ __ >> >> Furthermore you are building forwarding chain on the basis of >> ordered forwarding list of SIDs just hoping that the peer will >> accept the packet if his DA address is in the IPv6 header. Then it >> will look up his own SID and continue. ____ >> >> __ __ >> >> One thing I must agree with you that this is not Segment Routing ... >> In fact I am not sure how to call this architecture. Maybe forward >> referenced source routing ? ____ >> >> __ __ >> >> You can not do TI-LFA with this approach unless you pre-program any >> possible alternative paths to all nodes in the network. ____ >> >> __ __ >> >> Sure you can demo this in the lab or even on a network just like you >> could demo static mpls labels. Yes it is very simple and you got >> attention of few folks with that. And yes you could perhaps even >> show that if you just add few lines of xml config you could tunnel >> it across non CRH capable nodes ... But is this solution for any >> production network ? ____ >> >> __ __ >> >> I think and I was told by unicast emails that I am not alone - we >> are just guessing what the vehicle looks like after seeing the first >> wheel. So far it does not even look like a car ... maybe bike or >> scooter. Who knows .... ____ >> >> __ __ >> >> If I may recommend next action without dismissing your proposal a >> wise thing to do would be to get from you set of slides or perhaps >> youtube recording showing exactly not only all mapping distribution, >> but more over illustrating exact packet's header including CRH in >> all various cases I and others asked when packet is >> traversing throughout a controlled domain.____ >> >> __ __ >> >> Only after that we could start a new adoption call when more folks >> actually has a clear picture what it is being adopted here. Is it a >> brilliant and cool solution or is it some form of wild animal which >> can bite. ____ >> >> __ __ >> >> Many thx,____ >> >> Robert.____ >> >> __ __ >> >> __ __ >> >> On Thu, May 21, 2020 at 9:46 PM Ron Bonica <rbonica@juniper.net >> <mailto:rbonica@juniper.net>> wrote:____ >> >> Robert,____ >> >> ____ >> >> I am assuming that B is attached to Z. When I say, it isn’t >> attached, I mean that B isn’t attached to Link X->Y. Link X->Y >> is attached to Z.____ >> >> ____ >> >> Ron____ >> >> ____ >> >> ____ >> >> ____ >> >> Juniper Business Use Only____ >> >> *From:* Robert Raszuk <robert@raszuk.net >> <mailto:robert@raszuk.net>> >> *Sent:* Thursday, May 21, 2020 3:14 PM >> *To:* Ron Bonica <rbonica@juniper.net <mailto:rbonica@juniper.net>> >> *Cc:* 6man <6man@ietf.org <mailto:6man@ietf.org>> >> *Subject:* Re: Size of CR in CRH____ >> >> ____ >> >> *[External Email. Be cautious of content]*____ >> >> ____ >> >> > It isn’t attached to link X->Y. ____ >> >> ____ >> >> Please assume it is attached. ____ >> >> ____ >> >> I stated very clearly: "(or maybe even connected to B)"____ >> >> ____ >> >> Thx, >> R.____ >> >> ____ >> >> ____ >> >> ____ >> >> On Thu, May 21, 2020 at 8:45 PM Ron Bonica <rbonica@juniper.net >> <mailto:rbonica@juniper.net>> wrote:____ >> >> Robert,____ >> >> ____ >> >> Identifiers have node local scope. This means:____ >> >> ____ >> >> * One a single node, there is a one-to-one mapping between >> identifiers and the CRH-FIB entries that they identify____ >> * Nodes A through Z can all have a CRH-FIB entry that is >> identified by N. However, all of those CRH-FIB entries >> do not need to contain the same information.____ >> >> ____ >> >> Referring back to your example, Node B will never have the >> following entry in its CRH-FIB:____ >> >> ____ >> >> * Identifier = 15, IPv6 Address = Node Z, Method = strict, >> Link = X->Y____ >> >> ____ >> >> Why should it? It isn’t attached to link X->Y. So it >> couldn’t use that entry even if it had it.____ >> >> ____ >> >> >> Ron____ >> >> ____ >> >> ____ >> >> ____ >> >> ____ >> >> Juniper Business Use Only____ >> >> *From:* Robert Raszuk <robert@raszuk.net >> <mailto:robert@raszuk.net>> >> *Sent:* Thursday, May 21, 2020 11:25 AM >> *To:* Ron Bonica <rbonica@juniper.net >> <mailto:rbonica@juniper.net>> >> *Cc:* 6man <6man@ietf.org <mailto:6man@ietf.org>> >> *Subject:* Re: Size of CR in CRH____ >> >> ____ >> >> *[External Email. Be cautious of content]*____ >> >> ____ >> >> Hi Ron,____ >> >> ____ >> >> > Node B decrements Segments Left and looks for entry 15 in >> **its** CRH-FIB. If finds:____ >> >> > ____ >> >> > On Node B: Identifier = 15, IPv6 Address = Node C, >> Method = strict, Link = B->C____ >> >> ____ >> >> Your example works when the entire network has a single >> segment routed path :) ____ >> >> ____ >> >> What happens if also Node Z somewhere in the domain (or >> maybe even connected to B) advertised SID 15 with some >> different outbound link ? ____ >> >> ____ >> >> So Node B will have two FIB entries: ____ >> >> ____ >> >> Identifier = 15, IPv6 Address = Node C, Method = strict, >> Link = B->C ____ >> >> Identifier = 15, IPv6 Address = Node Z, Method = strict, >> Link = X->Y ____ >> >> ____ >> >> So how will B decided which one to use ? ____ >> >> ____ >> >> Best,____ >> >> R.____ >> >> ____ >> >> ____ >> >> ____ >> >> ____ >> >> On Thu, May 21, 2020 at 5:11 PM Ron Bonica >> <rbonica@juniper.net <mailto:rbonica@juniper.net>> wrote:____ >> >> Robert,____ >> >> ____ >> >> Let’s address your question with an example. Assume that >> Node A is sending a packet to Node D. The delivery path >> includes the following strictly routed hops:____ >> >> ____ >> >> * Node A to Node B over link A->B____ >> * Node B to Node C over link B->C____ >> * Node C to Node D over link C->D____ >> >> ____ >> >> Now we populate the CRH-FIB on Nodes B and C as follows:____ >> >> ____ >> >> * On Node B: Identifier = 15, IPv6 Address = Node C, >> Method = strict, Link = B->C____ >> * On Node C: Identifier = 15, IPv6 Address = Node D, >> Method = strict, Link = C->D____ >> >> ____ >> >> Now, Node A formats a packet as follows:____ >> >> ____ >> >> * IPv6 Destination Address = Node B____ >> * CRH Segments Left = 2____ >> * Identifier list = [15,15]____ >> >> ____ >> >> Node A sends this packet to Node B over link A->B.. Node >> B decrements Segments Left and looks for entry 15 in >> **its** CRH-FIB. If finds:____ >> >> ____ >> >> * On Node B: Identifier = 15, IPv6 Address = Node C, >> Method = strict, Link = B->C____ >> >> ____ >> >> So, Node B updates the IPv6 address and sends the packet >> to Node C over link B->C. Node C decrements Segments >> Left and looks for entry 15 in **its** CRH-FIB. If >> finds:____ >> >> ____ >> >> * On Node C: Identifier = 15, IPv6 Address = Node D, >> Method = strict, Link = C->D____ >> >> ____ >> >> So, Node C updates the IPv6 address and sends the packet >> to Node D over link C->D.____ >> >> ____ >> >> Ron____ >> >> ____ >> >> ____ >> >> ____ >> >> Juniper Business Use Only____ >> >> *From:* Robert Raszuk <robert@raszuk.net >> <mailto:robert@raszuk.net>> >> *Sent:* Thursday, May 21, 2020 10:35 AM >> *To:* Ron Bonica <rbonica@juniper.net >> <mailto:rbonica@juniper.net>> >> *Cc:* 6man <6man@ietf.org <mailto:6man@ietf.org>> >> *Subject:* Re: Size of CR in CRH____ >> >> ____ >> >> *[External Email. Be cautious of content]*____ >> >> ____ >> >> Ron, ____ >> >> ____ >> >> While we are at the local vs global significance of SIDs >> can you please elaborate how do you resolve the conflict >> where given SID value is advertised by more then one >> node ? In fact imagine that all nodes in a domain choose >> to advertise the same SID value "15" to forward the >> traffic to their respective peers. So packet arrives at >> segment endpoint node A with CRH consisting of SID list >> 15, 15, 15, 15 ... where each value 15 means different >> behaviour on different node. ____ >> >> ____ >> >> How do you even know which way to forward the packet ? ____ >> >> ____ >> >> See in this case your mapping plane will contain >> different functions on different nodes signalled with >> the same SID. ____ >> >> ____ >> >> I understand that you are trying to silently borrow >> set of procedures from SR-MPLS here as documented in >> RFC8660. But if you just open this RFC you will see >> section 2.5 or 2.6 without which you just can not simply >> propose to treat SID as locally significant in any form >> of segment routing. Of course unless you would consume >> two SIDs per node. ____ >> >> ____ >> >> Thx, >> Robert.____ >> >> ____ >> >> ____ >> >> On Thu, May 21, 2020 at 10:34 AM Robert Raszuk >> <robert@raszuk.net <mailto:robert@raszuk.net>> wrote:____ >> >> Ron, ____ >> >> ____ >> >> > Now recall that identifiers have node local >> significance. ____ >> >> ____ >> >> I was talking about case described in yr draft >> section 7: ____ >> >> ____ >> >> "Applications can:____ >> >> ____ >> >> o Allocate SIDs so that they have *domain-wide >> significance*."____ >> >> ____ >> >> While not a must - it is an option. So I believe my >> observation stays valid till draft either removes >> that option or describes scaling properties >> differences between both domain wide and local >> significance of the SIDs.____ >> >> ____ >> >> Thx,____ >> >> R.____ >> >> ____ >> >> ____ >> >> On Thu, May 21, 2020 at 4:01 AM Ron Bonica >> <rbonica@juniper.net <mailto:rbonica@juniper.net>> >> wrote:____ >> >> Robert,____ >> >> ____ >> >> Consider the following network:____ >> >> ____ >> >> * Contains 65,000 routers____ >> * Each router has 500 directly connected >> neighbors or fewer____ >> * Uses 16-bit CRH____ >> >> ____ >> >> In this network, each node might have 65,499 >> CRH-FIB entries:____ >> >> ____ >> >> * 64,999 CRH-FIB entries cause packets to >> follow the least-cost path to another node >> in the domain____ >> * 500 CRH-FIB entries cause packets to >> traverse a specific link to a specific >> neighbor.____ >> >> ____ >> >> As a mnemonic device, an operator might assign >> identifiers as follows:____ >> >> ____ >> >> * 0-65,000 identify CRH-FIB entries that cause >> packets to follow the least-cost path to >> another node in the domain____ >> * 65,001 – 65,565 identify CRH-FIB entries >> that that cause packets to traverse a >> specific link to a specific neighbor.____ >> >> ____ >> >> Now recall that identifiers have node local >> significance. So, Node A and Node B might both >> have a CRH-FIB entry that is identified by the >> value 65,001. However:____ >> >> ____ >> >> * The CRH-FIB entry on Node A causes packets >> to traverse a particular link towards Node X____ >> * The CRH-FIB entry on Node B causes packets >> to traverse a different link towards Node Y.____ >> >> ____ >> >> I think that this example refutes the premise of >> your argument, so there is not further need to >> address the conclusion.____ >> >> ____ >> >> Ron____ >> >> ____ >> >> ____ >> >> ____ >> >> ____ >> >> Juniper Business Use Only____ >> >> *From:* Robert Raszuk <robert@raszuk.net >> <mailto:robert@raszuk.net>> >> *Sent:* Wednesday, May 20, 2020 6:20 PM >> *To:* Ron Bonica <rbonica@juniper.net >> <mailto:rbonica@juniper.net>> >> *Cc:* 6man <6man@ietf.org <mailto:6man@ietf.org>> >> *Subject:* RE: Size of CR in CRH____ >> >> ____ >> >> *[External Email. Be cautious of content]*____ >> >> ____ >> >> HI, ____ >> >> ____ >> >> So just to make sure I understand this analogy >> of 16 bit -- 2^16 = 65536 nodes. I think this is >> only on paper. ____ >> >> ____ >> >> Imagine I have 1000 routers so if I divide the >> 16 bit space by 1000 I get at most 65 local node >> behaviours if anyone would like to embed such >> into the SID. ____ >> >> ____ >> >> That means that if my router have more then 65 >> interfaces I am not able to steer packets by src >> route out of my router ... I must always depend >> on the lookup of next SID how to forward the >> packets. ____ >> >> ____ >> >> That also means that if I want to apply any form >> of NP in segment endpoint I am quite limited to >> the number of local functions I could use. ____ >> >> ____ >> >> To conclude - Let me restate to what I and >> others already said - flat SID space domain wide >> in mapping plane is a mistake. Yes this is like >> MPLS, but this does not make it great again due >> to that legacy. ____ >> >> ____ >> >> Many thx, >> R.____ >> >> >> -------------------------------------------------------------------- >> 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 > -------------------------------------------------------------------- >
- Re: Size of CR in CRH Brian E Carpenter
- Re: Size of CR in CRH Erik Kline
- Re: Size of CR in CRH Joel M. Halpern
- Re: Size of CR in CRH Brian E Carpenter
- CRH and RH0 Darren Dukes (ddukes)
- RE: CRH and RH0 Ron Bonica
- Re: CRH and RH0 Darren Dukes (ddukes)
- Re: CRH and RH0 Bob Hinden
- RE: CRH and RH0 Ron Bonica
- Re: CRH and RH0 otroan
- RE: CRH and RH0 Ron Bonica
- Re: CRH and RH0 otroan
- RE: CRH and RH0 Ron Bonica
- Re: CRH and RH0 otroan
- RE: CRH and RH0 Ron Bonica
- Re: CRH and RH0 Bob Hinden
- RE: CRH and RH0 Ron Bonica
- RE: CRH and RH0 Pengshuping (Peng Shuping)
- Re: CRH and RH0 Tom Herbert
- Re: CRH and RH0 Robert Raszuk
- RE: CRH and RH0 Ron Bonica
- Re: CRH and RH0 Robert Raszuk
- RE: CRH and RH0 Ron Bonica
- RE: CRH and RH0 Ron Bonica
- RE: CRH and RH0 Ron Bonica
- Re: CRH and RH0 Robert Raszuk
- RE: CRH and RH0 Ron Bonica
- Re: CRH and RH0 Robert Raszuk
- RE: CRH and RH0 Ron Bonica
- Re: CRH and RH0 Stewart Bryant
- Re: CRH and RH0 Bob Hinden
- RE: CRH and RH0 Ron Bonica
- Re: CRH and RH0 Tom Herbert
- Re: CRH and RH0 Ole Troan
- Re: CRH and RH0 Darren Dukes (ddukes)
- RE: CRH and RH0 Ron Bonica
- Re: CRH and RH0 Bob Hinden
- RE: CRH and RH0 Ron Bonica
- RE: CRH and RH0 Ketan Talaulikar (ketant)
- RE: CRH and RH0 Ketan Talaulikar (ketant)
- Re: CRH and RH0 otroan
- RE: CRH and RH0 Ron Bonica
- Re: CRH and RH0 Darren Dukes (ddukes)
- Re: CRH and RH0 Tom Herbert
- Re: CRH and RH0 Erik Kline
- RE: CRH and RH0 Ketan Talaulikar (ketant)
- RE: CRH and RH0 Ron Bonica
- RE: CRH and RH0 Ron Bonica
- Re: CRH and RH0 Darren Dukes (ddukes)
- RE: CRH and RH0 Ketan Talaulikar (ketant)
- RE: CRH and RH0 Ketan Talaulikar (ketant)
- RE: CRH and RH0 Ron Bonica
- Adoption call criteria for CRH? [was: Re: CRH and… John Scudder
- Re: CRH and RH0 Mark Smith
- Re: Adoption call criteria for CRH? [was: Re: CRH… Robert Raszuk
- Re: CRH and RH0 Robert Raszuk
- RE: CRH and RH0 Ron Bonica
- RE: CRH and RH0 Ron Bonica
- Re: CRH and RH0 Gyan Mishra
- Re: Adoption call criteria for CRH? [was: Re: CRH… S Moonesamy
- Re: Adoption call criteria for CRH? [was: Re: CRH… Brian E Carpenter
- Re: Adoption call criteria for CRH? [was: Re: CRH… Darren Dukes (ddukes)
- Re: Adoption call criteria for CRH? [was: Re: CRH… Joel M. Halpern
- Re: CRH and RH0 Darren Dukes (ddukes)
- Re: Adoption call criteria for CRH? [was: Re: CRH… Brian E Carpenter
- Re: Adoption call criteria for CRH? [was: Re: CRH… John Scudder
- Re: Adoption call criteria for CRH? [was: Re: CRH… Bob Hinden
- Re: Adoption call criteria for CRH? [was: Re: CRH… Bob Hinden
- Re: Adoption call criteria for CRH? [was: Re: CRH… S Moonesamy
- Re: CRH and RH0 Tom Herbert
- RE: CRH and RH0 Ron Bonica
- RE: Adoption call criteria for CRH? [was: Re: CRH… Ketan Talaulikar (ketant)
- RE: Adoption call criteria for CRH? [was: Re: CRH… Pengshuping (Peng Shuping)
- Re: Adoption call criteria for CRH? [was: Re: CRH… Darren Dukes (ddukes)
- RE: CRH and RH0 Chengli (Cheng Li)
- RE: Adoption call criteria for CRH? [was: Re: CRH… Chengli (Cheng Li)
- Re: CRH and RH0 Robert Raszuk
- Re: CRH and RH0 Stewart Bryant
- Re: CRH and RH0 Robert Raszuk
- Re: CRH and RH0 Stewart Bryant
- Re: Adoption call criteria for CRH? [was: Re: CRH… Behcet Sarikaya
- Re: Adoption call criteria for CRH? [was: Re: CRH… Voyer, Daniel
- Re: Adoption call criteria for CRH? [was: Re: CRH… 刘毅松
- 答复: Adoption call criteria for CRH? [was: Re: CRH… qinfengwei
- Re: Adoption call criteria for CRH? [was: Re: CRH… Zafar Ali (zali)
- RE: Adoption call criteria for CRH? [was: Re: CRH… Andrew Alston
- Re: Adoption call criteria for CRH? [was: Re: CRH… Tom Herbert
- RE: Adoption call criteria for CRH? [was: Re: CRH… Ron Bonica
- Re: Adoption call criteria for CRH? [was: Re: CRH… Nick Hilliard
- Re: Adoption call criteria for CRH? [was: Re: CRH… Zafar Ali (zali)
- Re: [spring] Adoption call criteria for CRH? [was… Robert Raszuk
- Re: Adoption call criteria for CRH? [was: Re: CRH… John Scudder
- Re: Adoption call criteria for CRH? [was: Re: CRH… Fernando Gont
- Shorter SIDs in SR over IPv6 (Re: Adoption call c… Greg Mirsky
- Re: Adoption call criteria for CRH? [was: Re: CRH… Zafar Ali (zali)
- Re: Adoption call criteria for CRH? [was: Re: CRH… John Scudder
- Re: Adoption call criteria for CRH? [was: Re: CRH… Tom Herbert
- Re: Adoption call criteria for CRH? [was: Re: CRH… Robert Raszuk
- Re: Adoption call criteria for CRH? [was: Re: CRH… Mark Smith
- Re: Adoption call criteria for CRH? [was: Re: CRH… Tom Herbert
- Re: Adoption call criteria for CRH? [was: Re: CRH… Robert Raszuk
- Size of CR in CRH Bob Hinden
- RE: Size of CR in CRH Templin (US), Fred L
- Re: Size of CR in CRH Bob Hinden
- RE: Size of CR in CRH Templin (US), Fred L
- Re: Size of CR in CRH Tom Herbert
- Re: Size of CR in CRH Nick Hilliard
- RE: Size of CR in CRH Ron Bonica
- RE: Size of CR in CRH Templin (US), Fred L
- Re: Size of CR in CRH Brian E Carpenter
- Re: Size of CR in CRH Nick Hilliard
- Re: Size of CR in CRH Joel M. Halpern
- Re: Size of CR in CRH Bob Hinden
- RE: Size of CR in CRH Wang, Weibin (NSB - CN/Shanghai)
- RE: Size of CR in CRH Andrew Alston
- Re: Size of CR in CRH otroan
- RE: Size of CR in CRH Ron Bonica
- Re: Size of CR in CRH Bob Hinden
- Re: Size of CR in CRH Uma Chunduri
- RE: Size of CR in CRH Ron Bonica
- Re: Size of CR in CRH Tom Herbert
- RE: Size of CR in CRH Ron Bonica
- Re: Size of CR in CRH Tom Herbert
- RE: Size of CR in CRH Ron Bonica
- Re: Size of CR in CRH Ole Troan
- Re: Size of CR in CRH Mark Smith
- Re: Size of CR in CRH Fred Baker
- RE: Size of CR in CRH Ron Bonica
- Re: Size of CR in CRH Tom Herbert
- RE: Size of CR in CRH Robert Raszuk
- Re: Size of CR in CRH Bob Hinden
- On adddress sizing (was: Re: Size of CR in CRH) Toerless Eckert
- Re: Size of CR in CRH Toerless Eckert
- RE: Size of CR in CRH Ron Bonica
- RE: Size of CR in CRH Chengli (Cheng Li)
- RE: Size of CR in CRH Ron Bonica
- Re: Size of CR in CRH Robert Raszuk
- Re: Size of CR in CRH Nick Hilliard
- RE: Size of CR in CRH Ron Bonica
- RE: Size of CR in CRH Ron Bonica
- Re: Size of CR in CRH Zafar Ali (zali)
- Re: Size of CR in CRH Robert Raszuk
- Re: Size of CR in CRH Tom Herbert
- RE: Size of CR in CRH Ron Bonica
- RE: Size of CR in CRH Ron Bonica
- Re: Size of CR in CRH Robert Raszuk
- RE: Size of CR in CRH Ketan Talaulikar (ketant)
- RE: Size of CR in CRH Ron Bonica
- Re: Size of CR in CRH Robert Raszuk
- RE: Size of CR in CRH Ron Bonica
- Re: Size of CR in CRH Tom Herbert
- Re: Size of CR in CRH Robert Raszuk
- Re: Size of CR in CRH Zafar Ali (zali)
- RE: Size of CR in CRH Ron Bonica
- Re: Size of CR in CRH Joel M. Halpern
- Re: Size of CR in CRH Zafar Ali (zali)
- Re: Size of CR in CRH Bob Hinden
- RE: Size of CR in CRH Ron Bonica
- RE: Size of CR in CRH Ron Bonica
- Re: Size of CR in CRH Robert Raszuk
- Re: Size of CR in CRH Robert Raszuk
- Re: Size of CR in CRH Joel M. Halpern
- RE: Size of CR in CRH Pablo Camarillo (pcamaril)
- Re: Size of CR in CRH Joel M. Halpern
- Re: Size of CR in CRH Brian E Carpenter
- Re: Size of CR in CRH Gyan Mishra
- Re: Size of CR in CRH Gyan Mishra
- RE: Size of CR in CRH Wang, Weibin (NSB - CN/Shanghai)
- RE: Size of CR in CRH Ketan Talaulikar (ketant)