Re: [Idr] Color & TC semantics (was Re: I-D Action: draft-ietf-idr-bgp-ct-30.txt )
Ketan Talaulikar <ketant.ietf@gmail.com> Fri, 22 March 2024 08:49 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 3E1CFC18DB94 for <idr@ietfa.amsl.com>; Fri, 22 Mar 2024 01:49:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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_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=gmail.com
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 QMu372QtorRA for <idr@ietfa.amsl.com>; Fri, 22 Mar 2024 01:49:08 -0700 (PDT)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 4BBF3C151997 for <idr@ietf.org>; Fri, 22 Mar 2024 01:49:08 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-55a179f5fa1so2578810a12.0 for <idr@ietf.org>; Fri, 22 Mar 2024 01:49:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711097346; x=1711702146; 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=UxUUVjjZkotkMLQKz9p6ZrBeRRIG8RjVdaV25YJbCJ4=; b=nMn3CMPLXMHDjFTL/qURIFqhuDbgTDpF3Vm/UmiOhMLGvE26UYMsznl1y7NvRLm8P0 netg9lC4o7qyh79BIlhRv7sdF3GNQDn/XAFC+SrnQWf9ynq+K6aOHJfuFLBd6L2KSix+ F1IcoPQvoOi0I8xZ1Opx+a4uuQ4nX8oWJjoY+c7mHckfGITUwfOTx55xanN7+vjXTqpM Yc8M+uWQy0oGDOLrRmhBpOVpGIwOH7C01VoZYoh7a1xghu4nPX3KFdTwWAiKMSqP0Vhg Ci4RgcEeQo/auT5lDIlhZZGPy7NqDv40YHPQwxGdll656epswGSs+xlWSJ96c/oQHraK +eGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711097346; x=1711702146; 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=UxUUVjjZkotkMLQKz9p6ZrBeRRIG8RjVdaV25YJbCJ4=; b=W35Yd+mIfN17w9OvZEjXsDVnm3fuujkCFblRW53Re0mAFGTgPf/HWalQwNvBX+riLB oHAaAdI7/F0YYdkw2zNBsjFkb5FoaypOUnqDHfOxBV3e4lcCnhqtQBJyTz7KbQjuQzOI jfMbEwWAwJ7ED+Yd+FtR5cTn9NTTh8SqYQVkcDIGdZY+dHBbYK24ytzB01oRmIEAS/7e /8aUOogoYIQkgFu/UFsTxpeaIFH3xt27Nlwg6Y8wSaTp06h9XfdxomdnAHUAcwx84zos SlDdCoNzRjn1lothfVw7Tq0iwIMycpd59zQa+dSGRpTktU1fEn22EJRD7eIGCH7ZuEIp n95g==
X-Forwarded-Encrypted: i=1; AJvYcCVfRXT547fub1ul74U+Zbsdqm7jKGRcaMYKbPHcyC7YTuH77ayieNg+8iWGWygUiVbMIr+66o8lQP/qugg=
X-Gm-Message-State: AOJu0YxIgdOAojPj+3sa7+ExPSNmE/ME2utQk8lRI8JWTURY/GklSYRi RsoQo1yEbtVwaqAQw6vzZqZs2Sd7fZZASm9rmWYmjSLkBYsTHLTKCjLHBccljp8H/erx5hb1ofC Yze3xgrIyZn9WnktNgNbbotCfN8Y=
X-Google-Smtp-Source: AGHT+IHQQyCbsX451Ol4MHCAKoynPK2CXP9fVp0Sse2rGEoYv8uaRTrQwIj7sIwzYvsMKdPF52UzSDEv9BzfxpHRnCc=
X-Received: by 2002:a17:906:2b95:b0:a46:954a:aa14 with SMTP id m21-20020a1709062b9500b00a46954aaa14mr1210372ejg.67.1711097346268; Fri, 22 Mar 2024 01:49:06 -0700 (PDT)
MIME-Version: 1.0
References: <171073512993.15281.3471935824387385278@ietfa.amsl.com> <CAH6gdPw=w11HNJrQ-YzOtBEAnnVMLM66Yyyo97=jbec=r2R6wg@mail.gmail.com> <CAH6gdPzt7UYy1TdO5NDgJN4ypgWyZW0vkYFYqk_avWQXiTOKDA@mail.gmail.com> <DM6PR08MB4857E28AB1F6E76EA8817621B3312@DM6PR08MB4857.namprd08.prod.outlook.com>
In-Reply-To: <DM6PR08MB4857E28AB1F6E76EA8817621B3312@DM6PR08MB4857.namprd08.prod.outlook.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Fri, 22 Mar 2024 14:18:54 +0530
Message-ID: <CAH6gdPxEO=5ow7fG+Typ5FC07ksnpSk306CWEVUZD677GU+aBA@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Cc: Kaliraj Vairavakkalai <kaliraj@juniper.net>, "natv@juniper.net" <natv@juniper.net>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000080290e06143be532"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Adf504ctu1UDbXjJ6TTokGAkT1I>
Subject: Re: [Idr] Color & TC semantics (was Re: I-D Action: draft-ietf-idr-bgp-ct-30.txt )
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: Fri, 22 Mar 2024 08:49:12 -0000
Hi Sue, I don't mind if the registry is retained. Not using the registry was a solution - not the issue. My concern was: https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-30.html#section-13.4 As noted in Sec 4 and Sec 7.10, 'Transport Class ID' is interchangeable with 'Color'. *For purposes of backward compatibility with usage of 'Color' field in Color extended community, the range 1-4294967295 uses 'Private Use'* as Registration Procedure. Per RFC9012, there is no special semantics associated with the color value 0. The CT draft has introduced special semantics for TC ID 0 (this is not an issue) but seems to be associating those semantics to Color as well. Can you please clarify the intent here? I hope this document is not trying to change the semantics of the color value "0" in the Color extended community. Thanks, Ketan On Fri, Mar 22, 2024 at 2:11 PM Susan Hares <shares@ndzh.com> wrote: > Ketan and Kaliraj: > > > > Ketan thanks for mentioning this point. > > > > On the following comment from Ketan: > > > > “Doing IANA registration for TC-ID this way is quite pointless. We have > several instances in routing protocols where we define protocol > constant/special values [1].” > > > > IANA has checked Kaliraj’s usage of the registry. As it stands, Ketan’s > was the only comment on this matter of registry during the WG LC. I had a > long chat with Kaliraj at IETF-119 about the pros/cons of the registry. > He’s aware of all the choices of assignment. > > > > [Shepherd’s hat on] > > My current plan is to note this issue in my shepherd’s report. I will ask > if the IESG has a strong preference. If the IESG has a strong opinion, I’m > sure John Scudder will help me adjust it. > > > > At this point, I do not see any profit in holding up sending the document > to the IESG. > > [Shepherd]s hat off] > > > > Let me know what you think about this approach. > > > > Sue > > > > > > *From:* Ketan Talaulikar <ketant.ietf@gmail.com> > *Sent:* Thursday, March 21, 2024 11:05 PM > *To:* Kaliraj Vairavakkalai <kaliraj@juniper.net>; natv@juniper.net > *Cc:* idr@ietf. org <idr@ietf.org>; Susan Hares <shares@ndzh.com> > *Subject:* Re: [Idr] Color & TC semantics (was Re: I-D Action: > draft-ietf-idr-bgp-ct-30.txt ) > > > > > > A gentle reminder on this one please ... > > > > > > On Mon, Mar 18, 2024 at 6:00 PM Ketan Talaulikar <ketant.ietf@gmail.com> > wrote: > > Hi Kaliraj/Nats, > > > > I have one concern about this change introduced in the latest version of > the document. > > > > https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-30.html#section-13.4 > > > > As noted in Sec 4 and Sec 7.10, 'Transport Class ID' is interchangeable > with 'Color'. *For purposes of backward compatibility with usage of > 'Color' field in Color extended community, the range 1-4294967295 uses > 'Private Use'* as Registration Procedure. > > > > Per RFC9012, there is no special semantics associated with the color value > 0. The CT draft has introduced special semantics for TC ID 0 (this is not > an issue) but seems to be associating those semantics to Color as well. Can > you please clarify the intent here? > > > > If you remember, I had this concern with the introduction of a new term TC > for something that seems the same as Color. > > > > I had also suggested to simply do away with the IANA registration for TC - > ID and just specify in the spec the special semantics of zero TC-ID. Doing > IANA registration for TC-ID this way is quite pointless. We have several > instances in routing protocols where we define protocol constant/special > values [1]. > > > > Thanks, > > Ketan > > > > [1] An example from top of my mind is in ISIS > https://datatracker.ietf.org/doc/html/rfc5305#section-3 where > MAX_PATH_METRIC is defined or OSPF RFC2328 where LSInfinity is defined > without the need for an IANA registration. > > > > > > On Mon, Mar 18, 2024 at 9:42 AM <internet-drafts@ietf.org> wrote: > > Internet-Draft draft-ietf-idr-bgp-ct-30.txt is now available. It is a work > item of the Inter-Domain Routing (IDR) WG of the IETF. > > Title: BGP Classful Transport Planes > Authors: Kaliraj Vairavakkalai > Natrajan Venkataraman > Name: draft-ietf-idr-bgp-ct-30.txt > Pages: 75 > Dates: 2024-03-17 > > Abstract: > > This document specifies a mechanism referred to as "Intent Driven > Service Mapping". The mechanism uses BGP to express intent based > association of overlay routes with underlay routes having specific > Traffic Engineering (TE) characteristics satisfying a certain Service > Level Agreement (SLA). This is achieved by defining new constructs > to group underlay routes with sufficiently similar TE characteristics > into identifiable classes (called "Transport Classes"), that overlay > routes use as an ordered set to resolve reachability (Resolution > Schemes) towards service endpoints. These constructs can be used, > for example, to realize the "IETF Network Slice" defined in TEAS > Network Slices framework. > > Additionally, this document specifies protocol procedures for BGP > that enable dissemination of service mapping information in a network > that may span multiple cooperating administrative domains. These > domains may be administered either by the same provider or by closely > coordinating providers. A new BGP address family that leverages RFC > 4364 procedures and follows RFC 8277 NLRI encoding is defined to > advertise underlay routes with its identified class. This new > address family is called "BGP Classful Transport", a.k.a., BGP CT. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ct/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-30 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-idr-bgp-ct-30 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > >
- [Idr] I-D Action: draft-ietf-idr-bgp-ct-30.txt internet-drafts
- [Idr] Color & TC semantics (was Re: I-D Action: d… Ketan Talaulikar
- Re: [Idr] Color & TC semantics (was Re: I-D Actio… Ketan Talaulikar
- Re: [Idr] Color & TC semantics (was Re: I-D Actio… Susan Hares
- Re: [Idr] Color & TC semantics (was Re: I-D Actio… Ketan Talaulikar
- Re: [Idr] Color & TC semantics (was Re: I-D Actio… Susan Hares
- Re: [Idr] Color & TC semantics (was Re: I-D Actio… Ketan Talaulikar
- Re: [Idr] Color & TC semantics (was Re: I-D Actio… Kaliraj Vairavakkalai
- Re: [Idr] Color & TC semantics (was Re: I-D Actio… Ketan Talaulikar
- Re: [Idr] Color & TC semantics (was Re: I-D Actio… Kaliraj Vairavakkalai
- Re: [Idr] Color & TC semantics (was Re: I-D Actio… Ketan Talaulikar
- Re: [Idr] Color & TC semantics (was Re: I-D Actio… Susan Hares