Re: [Idr] IDR interim 25 September, -car type 2 - split to separate document?

Robert Raszuk <robert@raszuk.net> Mon, 25 September 2023 18:26 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D88C16952C for <idr@ietfa.amsl.com>; Mon, 25 Sep 2023 11:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0tQIxqQHiqY for <idr@ietfa.amsl.com>; Mon, 25 Sep 2023 11:26:28 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD356C169522 for <idr@ietf.org>; Mon, 25 Sep 2023 11:26:28 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-52f3ba561d9so15932213a12.1 for <idr@ietf.org>; Mon, 25 Sep 2023 11:26:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1695666386; x=1696271186; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=skz4SvRdJ4uQJ/zSvurVOEPZ3qWgUHU6x9ndaueq9s8=; b=BN6qOWZ9hQIlFZ8sFkAqMuPLy8pOAn8XNbKW5iPJEnwc3ltOFl96Jc57kO7ISrcN39 JX8yQ1DBVO2EVx7lfG/FffDA3eW7Uq3WdHkvLJk7FJIzXz/L8aOk6GRxOuo35MHeQLwo Q7DMVGWG6Gb6rUeFrhVRuC8SQmKDtDZf73UHQdKbkC+iVtAbtu2ADca/4+HwgudRcdEK /GCC3K93wBONjCy2xHRpGFNuuDO/3KByqkgpsEiB42RFRmhxVfy/mt7bca705S1oX1el fhcZOZziymwszbzAL+BnjWEyNg5wLgLWDqWtjzZCi5wjLa7KfarqG6jsLjqpG/2Qo909 OVgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695666386; x=1696271186; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=skz4SvRdJ4uQJ/zSvurVOEPZ3qWgUHU6x9ndaueq9s8=; b=PABd7Jwjp+8PSDL7V8oMo0u9wvO1R5gOhTtVdYAFqhIcHxJ/YT+P0nnKqbUWKTVPRp cDVOuschXJuN0JwgQEsQ0QNWxE3RYUoUPHxMlcvVFiHTokjE9T7XMYtp22XLeXVGkH71 iMbaMgghMPcKosSgzdve0fe9OnBfrlryHMfQ3L0FyQKxdV+MQ28/oOm0DMxmSBZjtFuV OKjbxCjbhMEYJQSXmxDXRKIezf+OofbNb3jYkOWK+qYezjBKmc7Yk6ft3m1bnJlfpm5e 5Abfra/PDqo8DOhiWMGbt9JBvGAFD9ogY38UBKC6FEJOmnAJb52DoljX/onEZvCG7UCs 35SQ==
X-Gm-Message-State: AOJu0YwTMiqrJMULOvBCYubD1FTaP6d36ymks4c4w97F7oij3TT0xeIU k/V6pwhzlk4bgp7ndJYSM7loXpJBXV8bd9Vl1ecnOQ==
X-Google-Smtp-Source: AGHT+IHzALIseDJngQP0X9dphEfsq/vfs6sUn5kLRno33F4l86WWpm8g5TISJRyhrJcSUArO6KMbhee6RsRjl0S2bus=
X-Received: by 2002:a05:6402:22b3:b0:530:8759:a3ac with SMTP id cx19-20020a05640222b300b005308759a3acmr780456edb.2.1695666386511; Mon, 25 Sep 2023 11:26:26 -0700 (PDT)
MIME-Version: 1.0
References: <20230925160002.GA5234@pfrc.org> <CAH6gdPya044WAadpAp=y664FDDkw-Hy3c8V3v5UyZvKSWCEXTw@mail.gmail.com> <8FABEE8E-AB97-47E2-9694-EFE697A09A5E@pfrc.org>
In-Reply-To: <8FABEE8E-AB97-47E2-9694-EFE697A09A5E@pfrc.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 25 Sep 2023 20:26:15 +0200
Message-ID: <CAOj+MMHagro10KBbKMGq4S=C5gg+1SWE==CDjLaGh7_RpYyDHQ@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: Ketan Talaulikar <ketant.ietf@gmail.com>, idr@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a040c90606331867"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/lswflKSjrOKFXs_EBEjQFNAObBQ>
Subject: Re: [Idr] IDR interim 25 September, -car type 2 - split to separate document?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Sep 2023 18:26:33 -0000

Hi Jeff,

If there's not always a LCM, then it's not really a route with color.  It's
> just something that's using convenient encoding - which is potentially
> reasonable.  But it's mixing the use case.
>

Well let's look at this from end to end network point of view.

I have a IPv6 based service which selectively needs to differentiate a few
infrastructure routes (aka locators or next-hops).

Maybe 5% of them.

So I may advertise my 95% of locators in type 2 CAR SAFI without any color
neither in NLRI nor in ext community. Then for those 5% I paint them with
ext community carrying some color.

My services may be available over both "colors" and depending on the SLA
forwarded to take grey (no color) or gold paths.

As you recall, the ability to aggregate routes is a very important feature
in any design. And the less we carry in the protocol the better.

Then last to me Type 2 is the proposal which addresses many previous
attempts to define separate next-hop SAFI (Ilya and I had one such attempt:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-nh-cost-01)  and
as I recall we were not alone in trying to define it.

As DJ reiterated today the entire idea behind CAR is to have easily
extensible SAFI to carry various infrastructure routes. I am not sure what
value is in splitting the document now other then just to delay the
progress. This is specifically considering experimental nature of the draft
where the bar by design is not as high as for standards track docs.

Kind regards,
Robert