Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE93C15155C; Thu, 17 Oct 2024 21:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 d0D4uPEmsZ2E; Thu, 17 Oct 2024 21:44:45 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2F0C1D4A8D; Thu, 17 Oct 2024 21:44:45 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-71e74900866so1081888b3a.1; Thu, 17 Oct 2024 21:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729226685; x=1729831485; 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=doy24s8nhG0RCd+C/Xty6J4IKAoRdmfP06PfWO3T+wA=; b=ex85CTcaiHQG7wMoweD1YsCw4Lxhh+8VyudB6PuKImSGT/Qb5jJRqv1q/Wy9vLmM5w KiQtfsIFl4prBqfI5LjmtIhPlGMx817/4dngBzdiKTMBEvoclUaIRgd+r1P93jdI1oCd v15DgsWBhL5aaK/HBXjrnawZLY7WNCQfuRXvTsOqEvsildtftiBUKBGrIfepgtfnDas5 Z7QJNW2GVofyp7O5ujYGjo8Bd2CdN4IY8Ksb+OpYx2loaIN/6WQ13D8HRkHdiagL4p41 sv+UrWj8EfQS65CxuztQwslRrYRbnNR9r/tDrw9+OeHyAHsmvRvhsYKROjc/YSOMMQn1 /QEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729226685; x=1729831485; 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=doy24s8nhG0RCd+C/Xty6J4IKAoRdmfP06PfWO3T+wA=; b=Nh36ZY6+aDzEjjuDtNpdmydmSio1jx2rY79jDc/exskHmNJeArMBOad5lO8K9PfWuN zHgFNr5Ev9cit47qhkxBLGeHA1BjiWzWvkCg6/rQTySHVT9y9nyzCnxS2UGBQkDnsKUA Gax4NvMzap7BeK7u/RZTT9AUSD834EAWAzj0wbhMxuJRiXH43K+Kw/Fvj6ip7hTF6k4F B5k5j4P51fufST49TjgTd+4jKmBsYVJo0oe5QF+J6AeCd84qDUrCJqSomRjyvpXvZw8w lEgd1mkm3OyLMNxOCAtQaA+dTL4nG0TwD8dJVZ1a6lfuFICu1vDvFqNQlyIR59M81xJD Agjg== X-Forwarded-Encrypted: i=1; AJvYcCV3ecyjaOZ+vUCBos5rRG7jFM8QafflNFLeLL5JvQ14PydTtwqOSntJPMxBhEBTU4RZ6agkvqMME5eqvg==@ietf.org X-Gm-Message-State: AOJu0YxBLCc7iRXXZmAGTb8UH74X3AGc69ULPaVZJeqFisnnK1ZGDWk9 HdG8awbWNqBzpUXWZIWAQJdH0UrZGIvaEjtUwy/cci3gFyahoLYasya5s3n2C1EF5N9ZRMipS26 R7JiNH/89uc8W2q+l/Dp59jBeooXofQ== X-Google-Smtp-Source: AGHT+IEIqVbrW9eY8qz0mj6f5PqdjkqGJboOafS22A/cQEnKMfWJltWhPhfhNGPBGO7h+aZ7uyQEupv2/a/wqoeIxE8= X-Received: by 2002:a05:6a00:2e04:b0:71e:72b5:3094 with SMTP id d2e1a72fcca58-71ea33d2ea0mr1913160b3a.28.1729226684853; Thu, 17 Oct 2024 21:44:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Fri, 18 Oct 2024 00:44:33 -0400 Message-ID: To: Vishnu Pavan Beeram Content-Type: multipart/alternative; boundary="0000000000004974c10624b8f653" Message-ID-Hash: F3RCHOFGSTKR4NMCNVPB5BSRRWDYOI6K X-Message-ID-Hash: F3RCHOFGSTKR4NMCNVPB5BSRRWDYOI6K X-MailFrom: hayabusagsm@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-teas.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: TEAS WG , TEAS WG Chairs X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BTeas=5D_Re=3A_Revisiting_NRP_Selector?= List-Id: Traffic Engineering Architecture and Signaling working group discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000004974c10624b8f653 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Pavan & Teas WG I think we should call the dedicated identifier field =E2=80=9CNRP Data Pla= ne ID=E2=80=9D. The NRP Selector ID is more like a classifier so the =E2=80=9CID=E2=80=9D = can be dropped and just call it NRP Selector. I agree with having flexibility of overloading existing fields or having dedicated field and the overloading as a good short term choice makes sense and dedicated field for long term. I agree the actual data plane encodings and length of the dedicated identifier should be handled by respective WG. I agree there has been discussion of avoiding adding state to control plane in LSR and IDR and that the same applies here in TEAS. On the strict match indicator I agree with having an explicit indicator to drop or map the packet that cannot be mapped to NRP. Actual encoding of strict match indicator should be handled by respective WG. Kind Regards Gyan On Wed, Oct 9, 2024 at 3:45=E2=80=AFPM Vishnu Pavan Beeram wrote: > We had a virtual interim meeting on May 29th 2024 to discuss the > following NRP Selector specific items: > > - Generic requirements and options for carrying NRP Selector in IP and > MPLS packets > - The relevant modeling aspects > - The data plane specific extensions that come into play when a > dedicated identifier is used as the NRP selector. > > > > The meeting minutes are captured at: > > - > https://datatracker.ietf.org/meeting/interim-2024-teas-01/materials/mi= nutes-interim-2024-teas-01-202405291400-00 > > > > We (the chairs) are starting a thread to close on some of the items > specific to having a dedicated identifier that is used as NRP selector > (note that NRP selector refers to the marking in the packet=E2=80=99s net= work layer > header that is used to associate the packet with an NRP). > > - What do we call this dedicated identifier field? > - =E2=80=9CNRP Selector ID=E2=80=9D and =E2=80=9CNRP Data Plane ID= =E2=80=9D have been proposed so > far. > - Length of the dedicated identifier field > - Is it okay for this to be different for different data-plane > types? > - A 32-bit field has been proposed for the IPv6 Data-Plane; A > couple of options =E2=80=93 8 bits and 13 bits =E2=80=93 have been = proposed for the MPLS > data plane > - Please note that the actual data-plane specific encodings are > outside the scope of the TEAS WG. > - =E2=80=9CStrict=E2=80=9D match indicator > - When a dedicated identifier is used as the NRP Selector, is it > useful to have an explicit indicator to determine what to do with a= packet > that cannot be mapped to an NRP? > - Drop the packet vs Map it to a default set of network resource= s > - The actual encoding of this =E2=80=9Cindicator=E2=80=9D could be = different for > different data-plane types and will need to be discussed in the res= pective > WGs (outside the scope of TEAS WG). > > > > Please chime in with your thoughts on these items. > > - Pavan and Oscar > > ps: @Jie =E2=80=93 Thanks for the offline prod. Please feel free to add o= ther open > items specific to NRP selector (that we may have missed) to the above lis= t. > _______________________________________________ > Teas mailing list -- teas@ietf.org > To unsubscribe send an email to teas-leave@ietf.org > --0000000000004974c10624b8f653 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Pavan & Teas WG
<= br>
I think we should call the dedicated identifier = field =E2=80=9CNRP Data Plane ID=E2=80=9D.

The NRP Selector ID =C2=A0is more like a classifier so t= he =E2=80=9CID=E2=80=9D can =C2=A0be dropped and just call it NRP Selector.= =C2=A0 I agree with having flexibility of overloading existing fields or ha= ving dedicated field =C2=A0and the overloading as a good short term choice = makes sense and dedicated field for long term.

<= /div>
I agree the actual data plane encodings and length o= f the dedicated identifier should be handled by respective WG.

I agree there has been discussion of= avoiding adding state to control plane in LSR and IDR and that the same ap= plies here in TEAS.

On t= he strict match indicator I agree with having an explicit indicator to drop= or map the packet that cannot be mapped to NRP.=C2=A0 Actual encoding of s= trict match indicator should =C2=A0be handled by respective WG.

Kind Regards=C2=A0

Gyan


= On Wed, Oct 9, 2024 at 3:45=E2=80=AFPM Vishnu Pavan Beeram <vishnupavan@gmail.com>= ; wrote:

We had a virtual interim meeting= on May 29th=C2=A02024 to= discuss=C2=A0the fo= llowing NRP Selector specific items:

  • Generic requirements and options for carrying NRP Selector = in IP and MPLS packets
  • The releva= nt modeling aspects=C2=A0
  • The dat= a plane specific extensions that come into play when a dedicated identifier= is used as the=C2=A0NRP=C2=A0selector.

=C2=A0=

The meeting minutes are captured at:

=C2=A0

We (the chairs) are starting a thread to close on some of the = items specific to having a dedicated identifier that is used as NRP selecto= r (note that NRP selector refers to the marking in the packet=E2=80=99s net= work layer header that is used to associate the packet with an NRP).=

  • What do we call this dedicated identifier field? =C2=A0
    • =E2= =80=9CNRP Selector ID=E2=80=9D and =E2=80=9CNRP Data Plane ID=E2=80=9D have= been proposed so far.
  • Length of the dedicated identi= fier field
    • <= font face=3D"arial, sans-serif" style=3D"font-family:arial,sans-serif;color= :rgb(33,33,33)">Is it okay for this to be different for different data-plan= e types?
    • A 32-bit field has been proposed for the IPv6 Dat= a-Plane; A couple of options =E2=80=93 8 bits and 13 bits =E2=80=93 have be= en proposed for the MPLS data plane
      • Please note that the actual data-p= lane specific encodings are outside the scope of the TEAS WG.=C2=A0<= /span>
  • =E2=80=9CStrict=E2=80=9D match indicator<= /li>
    • When a de= dicated identifier is used as the NRP Selector, is it useful to have an exp= licit indicator to determine what to do with a packet that cannot be mapped= to an NRP?
      • = Drop the packet vs Map it to a default set of network reso= urces
    • The actual encoding of this =E2=80=9Cindicator= =E2=80=9D could be different for different data-plane types and will need t= o be discussed in the respective WGs (outside the scope of TEAS WG).=

=C2=A0

Please chime in with = your thoughts on these items.

- Pavan and Oscar

<= p class=3D"MsoNormal" style=3D"margin:0cm;color:rgb(33,33,33)">ps: @Jie =E2=80=93 Thanks for the offline prod. Please feel free to = add other open items specific to NRP selector (that we may have missed) to = the above list.

_______________________________________________
Teas mailing list -- tea= s@ietf.org
To unsubscribe send an email to teas-leave@ietf.org
--0000000000004974c10624b8f653--