Re: Size of CR in CRH
Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 22 May 2020 21:43 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 6A5723A0ADA for <ipv6@ietfa.amsl.com>; Fri, 22 May 2020 14:43:06 -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 joiB5YjFVQpE for <ipv6@ietfa.amsl.com>; Fri, 22 May 2020 14:43:04 -0700 (PDT)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 E18903A0AD5 for <6man@ietf.org>; Fri, 22 May 2020 14:43:03 -0700 (PDT)
Received: by mail-pj1-x1033.google.com with SMTP id s69so5558808pjb.4 for <6man@ietf.org>; Fri, 22 May 2020 14:43:03 -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=VnjHiXjda84L/AYUmw5LOubasjI0Nthwv48l4BA6ev8=; b=XJtKCtHX5XmQBlQua6jMho8wzmxlbzwaKxdZ6h+YFwkNMAA9DbVMRsd/xh7vQK17U9 3hCj+Fj8b+U2q3nCsTOxxgBXiAKMIoQanpwoeY8bYP3rXLxdzJpHccain9XRn9UGPlsw SS15W6bQSWq8qz4s+JdMUMT6tCQ3JZa8Gg93d8WDI7QgWOEEE9C2A3rpzFprFZopMseV lvGHra4zqzMYE3HmS/nsjkQfKiYZguu0mVzeHpNSuzYtVyu9ZRp/1yU5zLwgAjpPZkgg /Ap+h3wHMjD8DInK6MmB0BH2Z2ERJ+9ovTu2N55xw3T4P+wF0lQhqpP9I+92TPQcKlR8 Xi7Q==
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=VnjHiXjda84L/AYUmw5LOubasjI0Nthwv48l4BA6ev8=; b=EKTx46x/kW+Aiod84uRlgybjBdb/2BShbvcDJNgap4/rVKTCCeesopVEsXZdVuZV39 sSNgGXU7YkuwJhAnH3ypUy+SYTACGsw4zmh7xToAIP6WZOtyYv3dV/eUqned9+vqj9QG RmBk8tRU/kqUA1k7YTwPhW86vdxDFNS5VrOf4DB6zqPaQLCggpP+irW02zjR8pwpO+eV nc0ycSlN3L7nVhNTfhSWLw5vymubJIvD73rghSAIek/i94C4q8Kt0gTzvLUADVrBD+rP y2cRpKoKSKm5xmNThmnQWGsXULnyv3WTsnFI1feb4e8I2i8tErGVjeU78fHLyzSQ7CfC 3jpA==
X-Gm-Message-State: AOAM531DuncIXaWST6hvsgWO77C5PkpXflcwbW3wVCCmylPHVMwSAfF0 p1Wvq1d2Sk5hhvhDuLo3m1lNJ+or
X-Google-Smtp-Source: ABdhPJyHDAT9MYdSih1ETWjutzQKF9QEnRHS/0eqU28qYpoW+Hhho/FxbCaWaApdrwY2GOH7qYIPqA==
X-Received: by 2002:a17:902:5988:: with SMTP id p8mr16994151pli.146.1590183781944; Fri, 22 May 2020 14:43:01 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id a2sm7504596pfi.208.2020.05.22.14.42.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 May 2020 14:43:01 -0700 (PDT)
Subject: Re: Size of CR in CRH
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: 6man <6man@ietf.org>
References: <CAOj+MMFsy=dDciY=TMwSf75CZCr_i1Mfv6oUiPs5U6hT2Bq94w@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> <9673ac60-f9a3-44c8-3c13-5f447302cfff@gmail.com> <e6cc5850-6ea4-da18-b8da-aa6a1afd213b@joelhalpern.com> <aad1fbe5-38de-52db-ebb7-f8d199de71ad@gmail.com> <6332cd9c-196c-da46-9e3f-88fe8a30ef95@joelhalpern.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <1c5b62ba-35f6-0a76-39bc-ce25bc8d2db6@gmail.com>
Date: Sat, 23 May 2020 09:42:57 +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: <6332cd9c-196c-da46-9e3f-88fe8a30ef95@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/lJdDTKZeghfdzS5haEiOHoVQ19E>
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 21:43:07 -0000
Thanks Joel. "Overloading" is a good choice of word. To be clear, my concern is not with operators choosing to overload addresses with specific semantics; it's that there seems to be a risk of proprietary overloading by vendors, and that can lead to interop issues and customer capture. Regards Brian On 23-May-20 02:40, Joel M. Halpern wrote: > CRH can be used with identifiers with all the overloading that the > SPRING architecture. Just as MPLS labels can be used that way. > > Much of that overloading behavior can also be delivered (with or without > CRH) by using destination options, as other drafts show. Which way you > want to use the CRH identifiers determines what their semantics are. > How you want to control your network then determines how you need to > distribute that information. > > the question of whether the decomposition of the Segment Routing > architecture proposed in SRm6 is an appropriate solution is one that > SPRING can debate. On the SRm6 document. We refreshed that because we > think it is useful information for the community. But it is not > necessary for evaluating CRH. > > Yours, > Joel > > PS: If we actually lived with our own architectures in routing, BGP > would be just an actual path vector reachability exchange rather than a > hammer that is being used for more different things than I can count. > > On 5/22/2020 1:42 AM, Brian E Carpenter wrote: >> Joel, >> >> The difference I see is that (according to what I've been able to >> understand about the SRH model, and extrapolating to the CRH model) >> the labels don't just map to next-hop address but also to some >> specific service or action tied to the label. In fact RFC8402 >> says this explicitly (emphasis added): >> >> Segment: an *instruction* a node executes on the incoming packet (e.g., >> forward packet according to shortest path to destination, or, forward >> packet through a specific interface, or, *deliver the packet to a >> given application/service instance*). >> >> SID: a segment identifier. Note that the term SID is commonly used >> in place of the term "Segment", though this is technically imprecise >> as it overlooks any necessary translation. >> >> So a SID value has semantics mapped to actions. This is the bit that >> doesn't seem to me is interoperable without more specification. >> >> If this doesn't apply to CRH, I apologise for being off topic. >> >> Regards >> Brian >> >> On 22-May-20 15:37, Joel M. Halpern wrote: >>> Well, it seeeems to work for MPLS without our having written that text :-) >>> >>> If you assume a central controller / NMS model (there are other models), >>> then the controller needs to understand what range of CRH entry values >>> each node in the domain can understand (if we use 32 bit values, not all >>> devices will support the same subset of 2 billion entries). It has to >>> know how (YANG model? Other mechanisms?) to tell each node how to >>> handle the entries it is responsible for. And it needs to know what >>> range the node can use for strict hops. >>> >>> How it gets that information has always been quite variable. For SR, >>> people tend to assume it is advertised in routing, but even for SR that >>> is not strictly required. >>> >>> Yours, >>> Joel >>> >>> >>> On 5/21/2020 11:04 PM, Brian E Carpenter wrote: >>>> 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)