Re: [Idr] Color-only bits in draft-ietf-idr-segment-routing-te-policy

Ketan Talaulikar <ketant.ietf@gmail.com> Thu, 17 February 2022 14:52 UTC

Return-Path: <ketant.ietf@gmail.com>
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 BCDC43A092F; Thu, 17 Feb 2022 06:52:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=gmail.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 oQmB339YS2g8; Thu, 17 Feb 2022 06:52:31 -0800 (PST)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 352453A092D; Thu, 17 Feb 2022 06:52:31 -0800 (PST)
Received: by mail-vs1-xe2c.google.com with SMTP id e26so6529189vso.3; Thu, 17 Feb 2022 06:52:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3bBUyvVCNcO6MR1sohla/uT1x4icjJyxd78zD0qzfUY=; b=kSMaUAgtdDnvD9QrTsblpAyJayIZ2FykS2NdBE8eFBOV3QEVFBMB5MXm/a+ISkPIMo iyIsqrcKNU5r/cl/S9YObz4X0wjtM1QtQdnbdcHdN6jzXfmO3JK1mJSm6vWwZtI1Lgz2 3LZtqvUC0kw5oCPlxfPIznmivTNFC4CYibfkvri/LV2GEF9pm8ksY+jDKXM5moEdDUsb 5tRgkU34ptI9N9/Jd3ctPPDE0yIOX5HLRUVMHc7u9IgWFom8P9WI2eTlN75PEfN9D6rl a4KmFRbRvKg3xz/5yCktWKP3xhR3FUe/MkXeiGSKubSWHWCsu/jLy+9I3QQ5CI25eHqb 27Ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3bBUyvVCNcO6MR1sohla/uT1x4icjJyxd78zD0qzfUY=; b=g7w2je+XyoJez1Y282K4hDDZ8LSVXyWR7VWq5Bxy8yOWj/6vdTyNa1LH06CoGQkQk+ kJtM2V66twldFkzcG3AiI0h5NyHKsGjmIT9tX+LCOoqvoTTKHugScZTy7xu0Xd/dMdoo V9o5g8q3E7G62ipqv81QNs3Z3CMqWLLCaoTe6LQSo7Cn4LIN737VxpfJdLIKw1Ax74Px PCgHrvXUfuZ7B4i6LT9K9iN57QFhPi+orGTybznWM7TEV9zF6nOWu91//gmGsOS/SMmd AZG/qlQTUeDnCz0JWDto5Ursd9lWXdR/repr6BgNvXPb4ewRnkkZU4ykx3snuh/Bufcs Gc4w==
X-Gm-Message-State: AOAM533PoVU6LuNkZgMqNQGfOVaz6x+wEh7leetJpkIDOJN3pZ9jBaEV Lcyqb8kKKzIF2xojCrLM0eyAszMXk71wymJpYwsbZJ4x
X-Google-Smtp-Source: ABdhPJzBPA3ZWCF2p8sUlCTQ5AXIJMAXjxPV0K4WCUw+Q64wneq0UeaPrOCKQFfRe99kwgkpNrTZaSM7UoShKlGDfpA=
X-Received: by 2002:a05:6102:34f4:b0:31b:9861:7cfa with SMTP id bi20-20020a05610234f400b0031b98617cfamr1297078vsb.64.1645109549928; Thu, 17 Feb 2022 06:52:29 -0800 (PST)
MIME-Version: 1.0
References: <939A4791-5A4A-4E7C-AB32-A09ABD3421B5@juniper.net> <CAH6gdPxRYJcvdCG9-BxuMvcfVQd=1xS9RvapdLxkJekty4eV8w@mail.gmail.com> <CBB34F23-2BC6-487B-8B1E-F1FD999F2988@juniper.net>
In-Reply-To: <CBB34F23-2BC6-487B-8B1E-F1FD999F2988@juniper.net>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Thu, 17 Feb 2022 20:22:17 +0530
Message-ID: <CAH6gdPyxUb8=q0aduqpEq93nYPdHQZKqKzwZKzkbRWz6GL2XtQ@mail.gmail.com>
To: John Scudder <jgs@juniper.net>
Cc: "draft-ietf-idr-segment-routing-te-policy@ietf.org" <draft-ietf-idr-segment-routing-te-policy@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000057132a05d837ea16"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/b24SjRSpSmo4TVxUuwhtr-bGmHE>
Subject: Re: [Idr] Color-only bits in draft-ietf-idr-segment-routing-te-policy
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 17 Feb 2022 14:52:36 -0000

Hi John,

I'll work on these changes along with my co-authors for the IDR document
first and share it with you/WG for feedback.

Thanks,
Ketan


On Thu, Feb 17, 2022 at 12:51 AM John Scudder <jgs@juniper.net> wrote:

> Hi Ketan,
>
> > On Feb 16, 2022, at 6:32 AM, Ketan Talaulikar <ketant.ietf@gmail.com>
> wrote:
> >
> > Thanks for your feedback and I agree that this is a somewhat odd
> situation. I also agree with your proposed changes and can work on them as
> a co-author of the IDR document.
>
> Thanks.
>
> > Would you have any suggestions on how to address the remainder of your
> concerns? Considering that this document is past WGLC in IDR, do you think
> this content could move from the IDR to the SPRING document?
>
> I would, instead, have imagined it moving in the other direction, both
> because it seems as though it makes more sense in the IDR doc, and because
> the SPRING doc is even further along (past WGLC, past IETF LC, scheduled
> for tomorrow’s IESG telechat). I don’t want to cross the streams of
> discussion more than necessary, but the reason I see it being more natural
> in the IDR than the SPRING doc is because "Given that
> [draft-ietf-spring-segment-routing-policy] is an architecture document, it
> describes the architecture and not really the protocol mechanisms. This is
> in line with other SPRING documents. The normative language for the BGP
> mechanism is in the IDR document.”
>
> I acknowledge it’s not a cut-and-dried question and there are other ways
> to resolve it that while less satisfying in terms of making the documents
> self-contained, also are less invasive. The minimal one, I guess, is to
> provide a table of names and values in the IDR document, something along
> the lines of
>
> Type Code       Symbolic Name   Description
> —————   ——————— —————
> 0                       Default handling        Steering falls back to
> default handling if no policy with color
> 1                       Prefer color            Steering favors following
> policies with the given color, but respects BGP next hop
> 2                       Override next hop       Steering favors following
> policies with the given color, overriding BGP next hop if necessary
> 3                       Reserved                        Reserved for
> future use
>
> You may not agree with the symbolic names and descriptions I’ve just
> written out, that’s fine, it’s just a first attempt. The table would be
> accompanied by an expansion of the descriptive prose in the section, to
> give the reader at least a general idea of what’s going on over in the
> SPRING doc.
>
> Also, the more I think about it, the more I think that creating an IANA
> registry for these code points is a good idea. It seems fussy for a single
> unallocated code point, but might prevent something unfortunate like two
> future drafts both trying to allocate the reserved code point for
> themselves.
>
> (I assume it’s way too late to move the field to the other end of the
> Reserved bits? If it were at the other end it would be possible to grow it
> naturally in the future if required, by allocating additional bits. As it
> is now, if you grew it by one bit, code point 1 would become code point 2,
> 2 would become 4, and so on. Or if you prefer, 0b01 would become 0b010,
> 0b10 would become 0b010, and so on. Oh well, too bad so sad.)
>
> —John