Re: Size of CR in CRH

Tom Herbert <tom@herbertland.com> Thu, 21 May 2020 20:04 UTC

Return-Path: <tom@herbertland.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 811D83A0791 for <ipv6@ietfa.amsl.com>; Thu, 21 May 2020 13:04:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 RRnmG_dBR3ml for <ipv6@ietfa.amsl.com>; Thu, 21 May 2020 13:04:11 -0700 (PDT)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 3BDD13A067A for <6man@ietf.org>; Thu, 21 May 2020 13:04:10 -0700 (PDT)
Received: by mail-ej1-x62d.google.com with SMTP id x20so10304485ejb.11 for <6man@ietf.org>; Thu, 21 May 2020 13:04:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7BOYUMiaOZXgvUjO0ZQk1jN9pI1AsBFofROdo2jOXyE=; b=VJCFpLpcQhHn5iuvcfLIpO2bva/bAWUqh16IqP+crXjaBUV9iq2jluhATUveZ8g7KZ 4KwfQ23mjSgqUuhVprlMQoI7ooruquBHz8dzIrqmbgyg2tkBX7A54Ns6qzJ1aPn3T+xc S6wTo2OPFoW59eICFJDzeeC34jy3LBe06gaoU/Q1dFfw8rQSNHVBVH/XevRzFX5uN1p0 /1ILNeWUh6V2tIYro8APOF5BuggZhGxE8pj1uoVxqLOGBHMrTYi2xYLc2rZi9eKTsSdF 1X8wl8Q8ClaIykG1/zdV98yio0iAqfKqhcyd77hA8FVzC4Fsv9DgPKXnVy29lwcsL4Hf mA7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7BOYUMiaOZXgvUjO0ZQk1jN9pI1AsBFofROdo2jOXyE=; b=RS6NtRbo9tuehvZPUO2WmP/c7n462dPeSmWeRQJA5jkFSDJyZPLNBz0a9DOplhKbxS Fj+qKutaE4mGxoAmls3FtKOjpRYqpu21UOkfV9hg3b5x64vYijlUfZ+B3dlzbRWNY2cX YcT61edGUnOCAFHdI8/QqqaCmc2EFJDVZDS38gx3s3owRt9ua3ID/VeF5SkyvhlfYiAy NDmDFUN/FO52zOMBPzJJ6eTY2+rqCbWB36BHsqtrAuJLT2Rtvv0qLl/uskM8A9z5rH7x 9emaYSz5CKchjLtXK8KoUaeLoASMlJJn+itditekwVla40/e8LEo1EZSy0gS913c3X/V MksA==
X-Gm-Message-State: AOAM5302VSibjKVU1H7X3/iEaTFUe7XSHrrAVn/4rcqGiHLnJGvvtXCj 9Qk7L+VnMB9u+VISWCGn/aFA12nGBSu3cTiM8ZpgLA==
X-Google-Smtp-Source: ABdhPJzcN4tcAUV3ET/oGhqtSVQsbO6Kg4boSwDBJCEyDdRlhcacnAmZZF2DrBH62zKt3Np1SJot1ex3CsQsDZ9U82A=
X-Received: by 2002:a17:907:438e:: with SMTP id oj22mr5258559ejb.195.1590091449134; Thu, 21 May 2020 13:04:09 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <DM6PR05MB63484502B4CFCB745DFCED3EAEB70@DM6PR05MB6348.namprd05.prod.outlook.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 21 May 2020 13:03:58 -0700
Message-ID: <CALx6S35hDq9MqSmcXaFjwULi=ce1gBAewTK5_Hq4R3LkN8HNEg@mail.gmail.com>
Subject: Re: Size of CR in CRH
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: Robert Raszuk <robert@raszuk.net>, 6man <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hCUqO907OdPpvMQfPyqYvnCj9tQ>
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: Thu, 21 May 2020 20:04:16 -0000

On Thu, May 21, 2020 at 8:11 AM Ron Bonica
<rbonica=40juniper.net@dmarc.ietf.org> 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:
>

Ron,

I think a route list of 15,15,15,15 working this way isn't naturally
intuitive and might be a bit hard to manage (without context this
looks to me like routing loops to me). Why wouldn't you want to assign
each node a domain scoped identifier? So if A->15, B->16, C->17, and
D->18 then a route list of 15,16,17,18 would visit A, B, C, D and have
consistent meaning across a domain?

Tom

>
>
> 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>
> Sent: Thursday, May 21, 2020 10:35 AM
> To: Ron Bonica <rbonica@juniper.net>
> Cc: 6man <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> 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> 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>
> Sent: Wednesday, May 20, 2020 6:20 PM
> To: Ron Bonica <rbonica@juniper.net>
> Cc: 6man <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
> --------------------------------------------------------------------