Re: Size of CR in CRH

Robert Raszuk <robert@raszuk.net> Thu, 21 May 2020 08:34 UTC

Return-Path: <robert@raszuk.net>
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 DB4A33A0AF7 for <ipv6@ietfa.amsl.com>; Thu, 21 May 2020 01:34:41 -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, HTML_MESSAGE=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=raszuk.net
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 AMJQETNyRmX9 for <ipv6@ietfa.amsl.com>; Thu, 21 May 2020 01:34:40 -0700 (PDT)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450: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 E1E813A0AF4 for <6man@ietf.org>; Thu, 21 May 2020 01:34:39 -0700 (PDT)
Received: by mail-ed1-x52d.google.com with SMTP id g9so6073532edr.8 for <6man@ietf.org>; Thu, 21 May 2020 01:34:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fy3EJSeZQfMkDUNcMk7yNYUxcKyRR3dY3gJCHZzSusU=; b=O/cNbV5AF5XrIgFb2l8treKUELNexZcCD0UBHv6qxQguKrKmh4VZyNykwQuPCsB1tB lcpAulVSjgGCJP+dmJw+238n58JvVL1NWL5zxPI8Tpy/25ZUbvwr6WioIalDS3H7CVdr 3e0lTe6Fnl0tNxO9g/Fv5te54jtGs1BGX1dFHfwacTG1HwkV/tUu4H8W0BQHoeNzno81 rZ+9id1Yxn6HqnqCPTPRvVQDcw+/aGBIvYqaK0VXAg9g85Qe5PMSdCFnC+TzyhRRzHgH 0drUE8sAyqu43A1DRAR0ZLJSzxfWLTiA5PJVKUFil6UAwQbGGcyTN3txUzHiTXJpfPtx eNZA==
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; bh=fy3EJSeZQfMkDUNcMk7yNYUxcKyRR3dY3gJCHZzSusU=; b=Ldv95wCZkIXWv9jQYT8K9jSdqfB6C4ol09dkNkdV43mWxNw1ebFeEmltfM2qUldIDt cj2jHhyttTg9IwhuXn9qEck6oGWjgPzW7yEq30tJ89JTfK3dOyKY4Oa2NouCTJ3uvVmU w8lnWSId4dMlh6ci52PTbccCR3yeZl+8a48i/3SDKYfuefSmJlFReGkananStOfyeNNv trjDuBJtbv2sF3CPUyoRf5qlAaBsXPie+DKDR5BYXyC1tDX8Sf9jXfHJUr7mAvv7X8y3 MOVrGRO8Iz7o6pJghGKRRAFz6U9Dt0Ymq/UUOlCzgmQu8gbZLqzltYyNcM+WJQXpabXT eKsg==
X-Gm-Message-State: AOAM531tF3j9q1McmZpLhjncBBYc5nIU1Ge4JWIZX+7bb0GnKpMLtwe8 w/v2mf6WcYZ3R/kN7J6CBSZqtsHTxBXl1fxXSzCjd4y4Rf0=
X-Google-Smtp-Source: ABdhPJxgT5JW0qVVuIF7lYZc96oI6p7wot/hGEJNTeseIAmci2gUb2XUnNY6kLWCWSXHX8sxtvvPhWUa3u0N6QjVWO0=
X-Received: by 2002:aa7:cb8f:: with SMTP id r15mr7171337edt.120.1590050077910; Thu, 21 May 2020 01:34:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAOj+MMFsy=dDciY=TMwSf75CZCr_i1Mfv6oUiPs5U6hT2Bq94w@mail.gmail.com> <DM6PR05MB6348D0DB381145F1A4C53450AEB70@DM6PR05MB6348.namprd05.prod.outlook.com>
In-Reply-To: <DM6PR05MB6348D0DB381145F1A4C53450AEB70@DM6PR05MB6348.namprd05.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 21 May 2020 10:34:27 +0200
Message-ID: <CAOj+MMHT=TWqf=A71PhvCcrFggCQ=okRrP=sGaO4hrcbmsCvGw@mail.gmail.com>
Subject: Re: Size of CR in CRH
To: Ron Bonica <rbonica@juniper.net>
Cc: 6man <6man@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000011b9e505a62462fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/icfjnZDncnP06-6JLWS5FpFiWwo>
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 08:34:42 -0000

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