Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8A2C180B4F; Wed, 26 Jun 2024 14:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 yIrmJELjo9dS; Wed, 26 Jun 2024 14:26:55 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 70035C180B71; Wed, 26 Jun 2024 14:26:55 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-57d280e2d5dso991429a12.1; Wed, 26 Jun 2024 14:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719437214; x=1720042014; 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=+t38kAzO9wYZy2AXqfrZ1yYU6c0UKSIblNY5a5KiIiw=; b=mmNWwMwcRlYmgwCfiHaRvbGVTTw3/lZROMD8weLUTKXSYQNBkLNPWTsooy4tLTPc8F zaXG9rv9rPxRaNqLpWmN3OpGyXGE/s2dr6VZ1fEKhZnlxVGPb578YuhfDcHfa1+tHTZr TVaOsA1lFhD4q/852e9qSbDTjFJtuwiRzWdYwCtGOuW6q3/irc8UnovD0fdh87GzdHAM ZQjMKBCXyewoowNgmY5H1wAtoaENtQ2D5J1qg/qiCpTjVhyUPBKEFsSctvrJd8MTgspI Yfh8phLh2kaIBIiJr5xDmFr18XW68NMsDRzpCVC1CrYvW+PJ/BsgSNcEGTEtq5Ta00Ke kr+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719437214; x=1720042014; 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=+t38kAzO9wYZy2AXqfrZ1yYU6c0UKSIblNY5a5KiIiw=; b=ktjcQJVpKIXxZj7IbQ/+HSdgOOkfb6nNSMLqaej+JqHYMv/8HOa+gmBt0uVW0TwQYs AS838uP3vXCnZ9FF6ndig5oS2YMJxingjYwTk/oko5E57rN3UPEA2ooxqrj5IhwMSE/T 04P/uZQxmsIA4Ae/mCD1vTFzZZrPuYNgzE6QdgLKqkiD1F0ENEM8ZoRm26mQ4etNljWO LIcT+nE3F/ATTlqxSVlgAI74wPw60N7U5IqM/MewQXXy+8abbfp2aMhXgBdqc07wHdyu BWq6b6Qn990pwJJS3zTnAUQTx+b7xpNscV5V5Nn4YrG0wv1fZHhuxy3HKEhPOTHX5tUS TINA== X-Forwarded-Encrypted: i=1; AJvYcCWo1WvzVcfkm1oipXS8+tJxtZiJnSiXG1ix0CMTVYChmc7s/xyeazLOm71tZ9Eh6zWMoiwSdUPTrnRyDMLphZcQZUk1n/T9ZGrHKnBqFVXBPvdpPVbMCJePEtXoGOgG2wsUZVwnbybGYgOHqnMDv8NL+Vaj3JeYG2Q5ETR3Z3DvH1M6/ywP3X+hKGTkiWp/HYaJLyQervugY6Bghje1y/NPOA== X-Gm-Message-State: AOJu0YzknAyQ0Ssj2XWvlldHqq2klHjLM3jp7RaVB1SDvvD9RBAS/rmV H/TdX1dpKECv54RNACMvKn7finQl2Xzq40GGUAAbT7TK9/wZWw3sKahS06G+Wyu2QCspk5k8FRB noZ1E/5jHpugUbxoYwLg6hyKUEQ== X-Google-Smtp-Source: AGHT+IH/KxtcCiVGm3SUA+83Mhx6DYnfmW82Al3P7CHs39VbOgdbFSMw2smLP7PmnFTMIb2DbGmJehZIsjyP8E4GYv0= X-Received: by 2002:a50:a417:0:b0:57c:9c5d:d195 with SMTP id 4fb4d7f45d1cf-57d4bdc9e02mr8017292a12.27.1719437213540; Wed, 26 Jun 2024 14:26:53 -0700 (PDT) MIME-Version: 1.0 References: <8bec7ee8-de8a-4559-b08d-e7699ea78c09@joelhalpern.com> <9bcc9f3c-063d-4c08-8f52-b0d873c353b9@pi.nu> In-Reply-To: <9bcc9f3c-063d-4c08-8f52-b0d873c353b9@pi.nu> From: Rakesh Gandhi Date: Wed, 26 Jun 2024 17:26:42 -0400 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary="00000000000053a9f2061bd1ac00" Message-ID-Hash: CP7KTIXXWNVGN3FAMFVDSQK2PJNMTJHJ X-Message-ID-Hash: CP7KTIXXWNVGN3FAMFVDSQK2PJNMTJHJ X-MailFrom: rgandhi.ietf@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mpls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "Jaganbabu Rajamanickam (jrajaman)" , "mpls-chairs@ietf.org" , mpls , "draft-jags-mpls-ps-mna-hdr@ietf.org" , draft-gandhi-mpls-mna-ioam-dex@ietf.org X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bmpls=5D_Re=3A_Request_WG_adoption_for_draft-jags-mpls-ps-mna-hd?= =?utf-8?q?r-03=2Etxt?= List-Id: Multi-Protocol Label Switching WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000053a9f2061bd1ac00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Loa. Those are good points. One more reason for carrying IOAM data fields and IOAM-DEX data fields in PSD! P.S. We had IOAM as well as IOM-DEX data fields carried in Post-Stack Data from the very early days of the MPLS IOAM draft due to such issues. Thanks, Rakesh On Wed, Jun 26, 2024 at 4:56=E2=80=AFPM Loa Andersson wrote: > Rakesh, Tnx for this, I think we are close with what you say here and > what I said in my review of draft-mb-mpls-ioam-dex > [ > https://datatracker.ietf.org/doc/review-mb-mpls-ioam-dex-06-rtgdir-early-= andersson-2024-06-17/ > ]. > > The -dex drafts would fit much nicer if we carried the AD as PSD. > > I also have a comment on your bullet 2 below. > > 2. IOAM data field format (32-bit) does not fit well into 32-bit ISD > LSE due to S bit (e.g., in 31-bit Format D), and it can result in > limitations, kind of defeats the use of standard IOAM formats > > There is an additional problem in Format D also the bit zero is > "taken", > it is set to "1", to avoid confusing the it with a bSPL. You only hav= e > 30 bits available, this does not make it easier. > > And, if you are going to transport a 22-bit sequence number that is b= y > definition mutable, and can't be transported in bit 1-19. It has to = in > the 11 bit 10-22 and 24-31. Since it is 22 bits it will take 2 Format= D > LSEs and make it even more different from the nice 32-bit aligned > fields > in the original dex-draft. > > I think this is a pretty good example of "case 2" in my previous > mail, it > possible to solve as >ISD, but becomes pretty awkward. Points to a PS= D > based solution. > > /Loa > > Den 2024-06-26 kl. 21:08, skrev Rakesh Gandhi: > > Hi Joel, > > > > Thanks for your review comment. > > > > Based on my understanding, some of the main motivations for adding > > IOAM direct export data fields in PSD instead of ISD would be: > > > > 1. IOAM data fields such as 32-bit Sequence Number or 32-bit > > Timestamp in an ISD LSE can lead to undesired ECMP behavior on > > nodes that use labels for ECMP hashing > > 2. IOAM data field format (32-bit) does not fit well into 32-bit ISD > > LSE due to S bit (e.g., in 31-bit Format D), and it can result in > > limitations, kind of defeats the use of standard IOAM formats > > 3. IOAM direct export supports extensibility to optionally add > > =E2=80=9Cunlimited=E2=80=9D number of data fields. When added as IS= D, node RLD > > would make it difficult to process the entire label stack > > 4. IOAM data fields for direct export (e.g., timestamp, sequence > > number, flow identifier, Namespace-ID, IOAM Option-Type, etc.) > > represent metadata (extra baggage) in the received packets > > * NPU simply exports these metadata (extra baggage) and does not > > really process them, there is not much motivation to place > > them in ISD. > > > > > > Based on the discussion, will update draft-gandhi-mpls-mna-ioam-dex-01 > > . > > > > > > > Thanks, > > Rakesh > > > > > > > > On Wed, Jun 26, 2024 at 10:06=E2=80=AFAM Joel Halpern > wrote: > > > > Rakesh, I tried to understand the explanation in your draft for > > why the iOAM DEX needs to be post-stack data. I could not parse > > it. Could you write an email that explains why you think it is > > needed? > > > > Thank you, > > > > Joel > > > > On 6/26/2024 9:12 AM, Rakesh Gandhi wrote: > >> Thanks Jags. > >> > >> The PSD solution for MNA defined in draft-jags-mpls-ps-mna-hdr-03 > >> is used for IOAM and IOAM DEX in draft-gandhi-mpls-mna-ioam-dex-01= : > >> > >> > https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-mna-ioam-dex-01 > >> > >> > >> IOAM and IOAM DEX use-cases for MNA are defined in > >> draft-ietf-mpls-mna-usecases-10: > >> > https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-usecases-10 > >> > >> The PSD solution is useful for IOAM and IOAM-DEX, I support the > >> request for WG adoption for draft-jags-mpls-ps-mna-hdr-03 (as > >> co-author). > >> > >> P.S. I understand this email was not the WG adoption poll > >> initiated by the chairs. > >> > >> Thanks, > >> Rakesh > >> > >> > >> > >> > >> > >> On Tue, Jun 25, 2024 at 10:52=E2=80=AFPM Jaganbabu Rajamanickam > >> (jrajaman) wrote: > >> > >> Hello Chairs, > >> > >> We would like to request WG adoption for > >> draft-jags-mpls-ps-mna-hdr. > >> > >> Updated the draft with the initial review comments and the > >> latest MNA header format. > >> > >> Welcome your review comments and suggestions. > >> > >> Thanx, > >> > >> Jags > >> > >> _______________________________________________ > >> mpls mailing list -- mpls@ietf.org > >> To unsubscribe send an email to mpls-leave@ietf.org > >> > >> > >> _______________________________________________ > >> mpls mailing list --mpls@ietf.org > >> To unsubscribe send an email tompls-leave@ietf.org > > > > > > _______________________________________________ > > mpls mailing list -- mpls@ietf.org > > To unsubscribe send an email to mpls-leave@ietf.org > > -- > Loa Andersson > Senior MPLS Expert > Bronze Dragon Consulting > loa@pi.nu > loa.pi.nu.@gmail.com > > --00000000000053a9f2061bd1ac00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Loa.

Those are good points. One more reason for carrying IOAM data fields and I= OAM-DEX data fields in PSD!

P.S. We had IOAM a= s well as IOM-DEX data fields carried in Post-Stack Data from the very earl= y days of the MPLS IOAM draft due to such issues.

<= div>Thanks,
Rakesh



<= div class=3D"gmail_quote">
On Wed, Jun= 26, 2024 at 4:56=E2=80=AFPM Loa Andersson <loa@pi.nu> wrote:
Rakesh, Tnx for this, I think we are close with what you say her= e and
what I said in my review of draft-mb-mpls-ioam-dex
[https= ://datatracker.ietf.org/doc/review-mb-mpls-ioam-dex-06-rtgdir-early-anderss= on-2024-06-17/].

The -dex drafts would fit much nicer if we carried the AD as PSD.

I also have a comment on your bullet 2 below.

2. IOAM data field format (32-bit) does not fit well into 32-bit ISD
=C2=A0=C2=A0=C2=A0 LSE due to S bit (e.g., in 31-bit Format D), and it can = result in
=C2=A0=C2=A0=C2=A0 limitations, kind of defeats the use of standard IOAM fo= rmats

=C2=A0=C2=A0=C2=A0 There is an additional problem in Format D also the bit = zero is "taken",
=C2=A0=C2=A0=C2=A0 it is set to "1", to avoid confusing the it wi= th a bSPL. You only have
=C2=A0=C2=A0=C2=A0 30 bits available, this does not make it easier.

=C2=A0=C2=A0=C2=A0 And, if you are going to transport a 22-bit sequence num= ber that is by
=C2=A0=C2=A0=C2=A0 definition mutable,=C2=A0 and can't be transported i= n bit 1-19. It has to in
=C2=A0=C2=A0=C2=A0 the 11 bit 10-22 and 24-31. Since it is 22 bits it will = take 2 Format D
=C2=A0=C2=A0=C2=A0 LSEs and make it even more different from the nice 32-bi= t aligned fields
=C2=A0=C2=A0=C2=A0 in the original dex-draft.

=C2=A0=C2=A0=C2=A0 I think this is a pretty good example of "case 2&qu= ot; in my previous
mail, it
=C2=A0=C2=A0=C2=A0 possible to solve as >ISD, but becomes pretty awkward= . Points to a PSD
=C2=A0=C2=A0=C2=A0 based solution.

/Loa

Den 2024-06-26 kl. 21:08, skrev Rakesh Gandhi:
> Hi Joel,
>
> Thanks for your review comment.
>
> Based on my understanding, some of the main motivations for adding > IOAM direct export data fields in PSD instead of ISD would be:
>
>=C2=A0 1. IOAM data fields such as 32-bit Sequence Number or 32-bit
>=C2=A0 =C2=A0 =C2=A0Timestamp in an ISD LSE can lead to undesired ECMP = behavior on
>=C2=A0 =C2=A0 =C2=A0nodes that use labels for ECMP hashing
>=C2=A0 2. IOAM data field format (32-bit) does not fit well into 32-bit= ISD
>=C2=A0 =C2=A0 =C2=A0LSE due to S bit (e.g., in 31-bit Format D), and it= can result in
>=C2=A0 =C2=A0 =C2=A0limitations, kind of defeats the use of standard IO= AM formats
>=C2=A0 3. IOAM direct export supports extensibility to optionally add >=C2=A0 =C2=A0 =C2=A0=E2=80=9Cunlimited=E2=80=9D number of data fields. = When added as ISD, node RLD
>=C2=A0 =C2=A0 =C2=A0would make it difficult to process the entire label= stack
>=C2=A0 4. IOAM data fields for direct export (e.g., timestamp, sequence=
>=C2=A0 =C2=A0 =C2=A0number, flow identifier, Namespace-ID, IOAM Option-= Type, etc.)
>=C2=A0 =C2=A0 =C2=A0represent metadata (extra baggage) in the received = packets
>=C2=A0 =C2=A0 =C2=A0 =C2=A0* NPU simply exports these metadata (extra b= aggage) and does not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0really process them, there is not muc= h motivation to place
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0them in ISD.
>
>
> Based on the discussion, will update draft-gandhi-mpls-mna-ioam-dex-01=
> <https://datatracker.= ietf.org/doc/html/draft-gandhi-mpls-mna-ioam-dex-01>.
>
>
> Thanks,
> Rakesh
>
>
>
> On Wed, Jun 26, 2024 at 10:06=E2=80=AFAM Joel Halpern <jmh@joelhalpern.com> wr= ote:
>
>=C2=A0 =C2=A0 =C2=A0Rakesh, I tried to understand the explanation in yo= ur draft for
>=C2=A0 =C2=A0 =C2=A0why the iOAM DEX needs to be post-stack data.=C2=A0= I could not parse
>=C2=A0 =C2=A0 =C2=A0it.=C2=A0 Could you write an email that explains wh= y you think it is
>=C2=A0 =C2=A0 =C2=A0needed?
>
>=C2=A0 =C2=A0 =C2=A0Thank you,
>
>=C2=A0 =C2=A0 =C2=A0Joel
>
>=C2=A0 =C2=A0 =C2=A0On 6/26/2024 9:12 AM, Rakesh Gandhi wrote:
>>=C2=A0 =C2=A0 =C2=A0Thanks Jags.
>>
>>=C2=A0 =C2=A0 =C2=A0The PSD solution for MNA defined in draft-jags-= mpls-ps-mna-hdr-03
>>=C2=A0 =C2=A0 =C2=A0is used for IOAM and IOAM DEX in draft-gandhi-m= pls-mna-ioam-dex-01:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-mna-io= am-dex-01
>>
>>
>>=C2=A0 =C2=A0 =C2=A0IOAM and IOAM DEX use-cases for MNA are defined= in
>>=C2=A0 =C2=A0 =C2=A0draft-ietf-mpls-mna-usecases-10:
>>=C2=A0 =C2=A0 =C2=A0htt= ps://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-usecases-10
>>
>>=C2=A0 =C2=A0 =C2=A0The PSD solution is useful for IOAM and IOAM-DE= X, I support the
>>=C2=A0 =C2=A0 =C2=A0request for WG adoption for draft-jags-mpls-ps-= mna-hdr-03 (as
>>=C2=A0 =C2=A0 =C2=A0co-author).
>>
>>=C2=A0 =C2=A0 =C2=A0P.S. I understand this email was not the WG ado= ption poll
>>=C2=A0 =C2=A0 =C2=A0initiated by the chairs.
>>
>>=C2=A0 =C2=A0 =C2=A0Thanks,
>>=C2=A0 =C2=A0 =C2=A0Rakesh
>>
>>
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0On Tue, Jun 25, 2024 at 10:52=E2=80=AFPM Jaganb= abu Rajamanickam
>>=C2=A0 =C2=A0 =C2=A0(jrajaman) <jrajaman=3D40cisco.com@dmarc.ietf.org&g= t; wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hello Chairs,
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 We would like to req= uest WG adoption for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-jags-mpls-ps-mna-hdr.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 Updated the draft wi= th the initial review comments and the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0latest MNA header format.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Welcome your review commen= ts and suggestions.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanx,
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jags
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_________________________________= ______________
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mpls mailing list -- mpls@ietf.org
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To unsubscribe send an email to <= a href=3D"mailto:mpls-leave@ietf.org" target=3D"_blank">mpls-leave@ietf.org=
>>
>>
>>=C2=A0 =C2=A0 =C2=A0_______________________________________________=
>>=C2=A0 =C2=A0 =C2=A0mpls mailing list --mpls@ietf.org
>>=C2=A0 =C2=A0 =C2=A0To unsubscribe send an email tompls-leave@ietf.org
>
>
> _______________________________________________
> mpls mailing list -- mpls@ietf.org
> To unsubscribe send an email to mpls-leave@ietf.org

--
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
loa@pi.nu
loa.pi.nu.@gmail.= com

--00000000000053a9f2061bd1ac00--