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