Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Robert Raszuk <robert@raszuk.net> Fri, 29 May 2020 17:11 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 E25433A0E1F for <ipv6@ietfa.amsl.com>; Fri, 29 May 2020 10:11:39 -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 9a5eEfUJ7kMK for <ipv6@ietfa.amsl.com>; Fri, 29 May 2020 10:11:38 -0700 (PDT)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 CBD193A0E1E for <6man@ietf.org>; Fri, 29 May 2020 10:11:37 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id q13so2292733edi.3 for <6man@ietf.org>; Fri, 29 May 2020 10:11:37 -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=kG5Nsn1x1ojB3zMU+p91Q1fkiLzct2lV5dDZLVLqL4s=; b=W2inWWaLuG50i39rxR7tk2bQObnT+l5omqdhusk0vnzPfmFt/GKYVpor1wK6oPaUE/ SqSktFSrTPDNw4e+d9HtryYI0Zz48FWTh6SqvLpwBCtFuIlTQNzvZ3hbeD4QAU7wFOXB IrjOph1Fu+3kO2iRuI+XYKImmBd9Q0QGn0NiJ2WNSYRp/5hK29KP83HjubvJaMgM6Rls l439cfFlqwKS31YxPY+IxGnBER3QV3qPNjVuxc+BPmTnnwA+H3rvbyTePPJpO9S/LSjU iU8rnsxpocdV4JzBwrvU9aNWlUzlRGsn+XVyhjU1k9xq0ypJyAhtbLpoGkjIYnzWzyHS YX4A==
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=kG5Nsn1x1ojB3zMU+p91Q1fkiLzct2lV5dDZLVLqL4s=; b=AdOJggQnXTn5DGxo5qZlOp9wP1NKO+f7gt/eGVicH0LbH5leDCCPj/afPr9CBi0+fG rLYDJwQzQgff3T5OzOrnf+TRbheVr9ojoWd/9a/xo1gdGJHN6HyOOnvx2HGdgKjkQuph pvkmCecl6v6euZb7fPDpgn01kengfDsUFHRQupSg3hETfK9nYDJ7Ai9zw7DBmNWWnBFt CLSrpJK8ZrIpoljHdpBAUtKkNsohekM3bUxC8DdAMVGj5UJFyFB2lcxGZf7vkvaFP6n9 w/q0i+81HdEXneIuNRnvzPzHoL3ibMrs9UdaziBDfAkiwW9poAFtDCxhccOFCmHZFkh2 zEdg==
X-Gm-Message-State: AOAM533BGRLJSRhE8fhFDvNw39fmDu/CqJfMp6UwTYSx7++PkLORfnDh AVpWXS81bAQ4akThTGaMzMc80QmSD4R0cXZYY3/3WQ==
X-Google-Smtp-Source: ABdhPJwcxF7FG3w4Uyad/OCIqdoHycEEJYrEolyn61Bhp6ucWnqzkBq71Fdvv6NBkfPeGAFeFFIInrBAy8nV0156OAA=
X-Received: by 2002:a50:e711:: with SMTP id a17mr9325376edn.369.1590772296190; Fri, 29 May 2020 10:11:36 -0700 (PDT)
MIME-Version: 1.0
References: <9CF68CCE-B584-4648-84DA-F2DBEA94622D@cisco.com> <ec63e90e-19fa-cd6c-eacb-4dee44815c99@joelhalpern.com> <MW3PR11MB4570FB2397D4B28A42626802C1B40@MW3PR11MB4570.namprd11.prod.outlook.com> <3bbb28c8-0106-ad63-abf9-c9dc4e428e0c@joelhalpern.com> <MW3PR11MB4570FD37ED32519C677F5E59C1B20@MW3PR11MB4570.namprd11.prod.outlook.com> <DM6PR05MB63486B842CD9DF5BE57FC1A5AEB30@DM6PR05MB6348.namprd05.prod.outlook.com> <MW3PR11MB45706D51FBE6CD63B58CDF15C1B30@MW3PR11MB4570.namprd11.prod.outlook.com> <DM6PR05MB634848BE997686F212FF9E49AEB30@DM6PR05MB6348.namprd05.prod.outlook.com> <MW3PR11MB457006B3ECAF2E812CD2E721C18E0@MW3PR11MB4570.namprd11.prod.outlook.com> <df0b518a11734e8f91dc2c0902f46df5@nokia-sbell.com> <DM6PR05MB6348EBA8F4E6C889393B5269AE8E0@DM6PR05MB6348.namprd05.prod.outlook.com> <a2876051-182b-f955-6e52-17740a612c74@cisco.com> <AC07D522-C10B-47CE-8B79-10EFDEA440D7@juniper.net> <ea9a0467-c9a6-11bf-5454-d6bc44b8d2ad@cisco.com> <3C511772-D3E8-4A80-AE73-43E644759C1D@juniper.net> <0ed7a981-d890-03e4-86b9-64d42c971552@cisco.com> <A049C501-EBB8-467E-96BB-6E01144DC527@juniper.net>
In-Reply-To: <A049C501-EBB8-467E-96BB-6E01144DC527@juniper.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 29 May 2020 19:11:27 +0200
Message-ID: <CAOj+MMHGF_3NwcUxjk7i6y776y0yWQSuGy1s6tN+zae5xrK9Yg@mail.gmail.com>
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>
Cc: Peter Psenak <ppsenak@cisco.com>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "spring@ietf.org" <spring@ietf.org>, 6man <6man@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a2281c05a6cc893e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/C5FgfhYat9RqsMY_VfjIYaKcNHo>
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, 29 May 2020 17:11:40 -0000

John,

Draft under the adoption call as well as its author sent 10s if not more
messages stating that CRH-SIDs are **locally significant*. *

Now after few discussions about scaling aspects of such design choice you
are suddenly stating:

*" one exemplary solution to your objection is to make use of
globally-unique (per domain, of course) identifiers"*

so at this point the main characteristics of the proposal seems at least
very elastic.

With that what exactly is the proposal 6man is subject to adopt if it is
fundamentally changing every day ?

Note that if IDs are globally domain wide significant then you suddenly
need to worry about ID space collision. Would next the index would be
introduced just like SR-MPLS addresses that problem ?

I remain with my opinion that current draft is not even stable enough for
adoption in any WG.

Regards,
Robert.



On Fri, May 29, 2020 at 4:56 PM John Scudder <jgs=
40juniper.net@dmarc.ietf.org> wrote:

> Peter,
>
> On May 29, 2020, at 10:36 AM, Peter Psenak <ppsenak@cisco.com> wrote:
>
> well, advertising the local CRH identifier for every node and adjacency
> in the network from every other node is clearly a no-go from the IGP
> perspective.
>
>
> (Of course this objection only applies to the final (“distributed routing
> protocol”) bullet point.)
>
> We’re recapitulating conversation that has been done on-list at least
> once. If I had time I’d find the reference and post, but as we know the
> conversation is hundreds of messages deep (at least!) and I don’t; sorry.
> Maybe someone else has a reference handy? If I recall correctly (and I may
> not) one exemplary solution to your objection is to make use of
> globally-unique (per domain, of course) identifiers, and yes, I do mean
> something semantically similar to a SR Node-SID. Other solutions are
> possible, depending on the use case — if the use case doesn’t require
> any-to-any connectivity within the domain, you potentially don’t need
> O(N^2) CRH identifiers to be present in the LS(P)DB even absent any kind of
> global uniqueness. Granted that any-to-any is the most general case.
>
> Not to mention that the proposed encoding in
> draft-bonica-lsr-crh-isis-extensions only allows one to advertise the
> CRH identifier for a local prefix and adjacency, not for the remote ones.
>
>
> That seems out of scope for discussion of CRH per se, unless you mean to
> say “this problem cannot be solved” instead of “this particular solution is
> deficient”. If it’s the latter, I think the LSR mailing list seems like a
> better place to take it up with the authors
> of draft-bonica-lsr-crh-isis-extensions.
>
> —John
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>