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: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212BA3A0E27 for <spring@ietfa.amsl.com>; Fri, 29 May 2020 10:11: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=unavailable 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 8t7MfTBKGz17 for <spring@ietfa.amsl.com>; Fri, 29 May 2020 10:11:39 -0700 (PDT)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 41BC43A0E25 for <spring@ietf.org>; Fri, 29 May 2020 10:11:39 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id g9so2270207edw.10 for <spring@ietf.org>; Fri, 29 May 2020 10:11: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=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=XlF9rlRsteapPFsgm0vBvdslvFZKdK9ARNdmlv/iYO7VtT06TGUNmEwhEiyKBfR34F u86fxeyEOHAB4sD0D/6cMqu2RYFPG9qR2HK+hBHiHznwY13jSOt788B20LVN9ViQ/wzP wQyF8iALSRPLLyAHTKImEYu5EFh4AG6WYKjwjLp/In3F9+NkDv5+OlGY7R9Vrre5FRtl WnQxTWiT33uZQXL+ell1jPZjtdwF8UVP/C0eLmfNAfcGafvsoRPa6HqaY8PkQHYRuMYQ WBflOd+Vjpt3Uk9pQKXQkSyJHVnQa+goQ21plJtJJm9pkeZ4wyRTP+UMeLOVp/RJNybi q3tw==
X-Gm-Message-State: AOAM533+kp2oaPzhwhcMGGCyxtDAQsh2Gcdn6GdsGC6zFoJLCYK+FF73 Luqw363jez7BZrwt5mMoz0ZJWQvBdBqtB/MRcqNhfQ==
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>
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/spring/eRF1ADiAHbEepvIq48p7kqKbnGk>
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2020 17:11:42 -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
> --------------------------------------------------------------------
>