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 5BBE4C14F6A1; Thu, 27 Jun 2024 06:25:53 -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 2J1YvM7bFMvo; Thu, 27 Jun 2024 06:25:52 -0700 (PDT) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 7C678C14F699; Thu, 27 Jun 2024 06:25:52 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id 3f1490d57ef6-e034b3e95adso312434276.0; Thu, 27 Jun 2024 06:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719494751; x=1720099551; 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=4wZHZmiMsjVjIz50nJEADiDJ0PSpa9dmgRM9EQ5HnWI=; b=PYQx7Za8YmNJe5YQSeskSZ2nZAqb4B9lywq2u/Fwq4B51P2clw4wg+JycajOz5f3uO KvYGmj+k7JRVYLGxXbxh/5HHcQUzAbaTh0cFlVPrWZQX0UeWYU85V2kc095gQLfCi2oZ o/UP6qgbZJs3MCfZ72K4+n6K+ddvGB2JTBWGpkPZIWZOM3BSVi1zLMWdhDJ2OAVnzgQE 7aNvrmpZcdpmbY4DOtA007ipBWdrMCJ4lwcHwGaHF0nkWkZ7s23CeRjbXQhTa61KrZoT SK9ltf2aqJ0j32k1ONizqh07OaYkK2tllhBcyfoFn+J9bbxeZPT3oaDVl0KF4RGNkGqw /jKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719494751; x=1720099551; 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=4wZHZmiMsjVjIz50nJEADiDJ0PSpa9dmgRM9EQ5HnWI=; b=BGiESWgsoFac4cAhlrNI2OX5Dbrb5Yb2x6RMNiL+FhwgD0A2GA0VG8wMz8F6/H+2RA k0Tbc/J1efFxev4kuvEOnIyYao6zD/dNidYAPrFcg2i4SLXD/WmBc0uFA+juoVNh1M8J Jk3ec0uaXr1d10CHB1lO5+Kv0VXl4JNISDzzcx1HyYu9vmni59ixkjhOnlIQW+RSvIHy /AeHjXXfojLtKC7Uxlbe74nXAWpMOO6R+gi2phlFZq1b40WGGmDmoOWXSnugdCaMiX9I 7vH1b6iT1S4zYaIU3pWLwLa/bO1bFN+XAw5wd87fjSeysCJj/cnkw0OY/zovD0VpjukM iTaA== X-Forwarded-Encrypted: i=1; AJvYcCUXUWPEUqr5X3EI0ydPwGpJQJrP2Om1zl27AGgDtvNsdeRBsH/NaKXZdnCa5dZxpdG9AD7LJlOIPTNqF3f7YO/0JrRi7vjld6B7W1qgEDTRNwupeAyM0ZaMxR7QW1PS8bateg== X-Gm-Message-State: AOJu0Ywz2JKh/SFTb/NkTEkjuSYL3T0fpBTuuBe2dowbjGoED/lahrww DImB9nS8EdHuS7t9ZzkIVFwI5GNeRKcKF/dhstr6Dqvd+WEka66WBAQdOjtL6P2Gr/p1xgOv85o 1BnDtNSsevN4N3fmF4MgS20rPIzmvzPpZ X-Google-Smtp-Source: AGHT+IHg06bKCQXNaFBls/tR8Me2VbeK2TzFafADB6LN+PND1DRNXGYV+DII5sjZAhgYTX0TBG8XVK1ezKH8bVu7/hQ= X-Received: by 2002:a25:8587:0:b0:dff:30c7:8e08 with SMTP id 3f1490d57ef6-e0346a9ee6amr827370276.32.1719494751328; Thu, 27 Jun 2024 06:25:51 -0700 (PDT) MIME-Version: 1.0 References: <20fade0a-e70a-4e62-a9d3-504e29940843@pi.nu> <7c285cf9-8f6c-4a57-b340-77e0772bef9b@joelhalpern.com> <74fb062b-3342-47e8-a62c-d160a04e5600@pi.nu> In-Reply-To: <74fb062b-3342-47e8-a62c-d160a04e5600@pi.nu> From: Greg Mirsky Date: Thu, 27 Jun 2024 06:25:40 -0700 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary="000000000000d8a3b5061bdf117e" Message-ID-Hash: YFXOA2WA4LY3YKIXORVHXQNZXEKATBDE X-Message-ID-Hash: YFXOA2WA4LY3YKIXORVHXQNZXEKATBDE X-MailFrom: gregimirsky@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: mpls , "draft-jags-mpls-ps-mna-hdr@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: --000000000000d8a3b5061bdf117e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Loa, thank you for sharing your opinion. I do agree that mutability of IOAM-DEX, as mutability in general, is a restricting aspect in ECMP environments that use the label stack information to generate entropy used in load-balancing. I read the latest version of the draft and have several questions on it and your notes: - You mention timestamp in connection with IOAM-DEX. Could you please point out to me where and how a timestamp information is used in RFC 932= 6 , draft-mb-mpls-ioam-dex , or draft-jags-mpls-ps-mna-hdr ? - As I understand RFC 9326 , the Sequence Number is optional and is not used for Loss Measurement but= , in combination with the Flow ID, help correlating telemetry information generated by the same packet equipped with the IOAM-DEX. In your opinion= , how large space is useful for the Sequence Number for the purpose descri= bed in RFC 9326 ? - And a more general question. How draft-jags-mpls-ps-mna-hdr can be used in RLD-limited environment? Regards, Greg On Thu, Jun 27, 2024 at 3:11=E2=80=AFAM Loa Andersson wrote: > Joel, wg, wg-chairs, > > No I don't think we are in the first case, ISD and PSD is not equally goo= d > for all cases. > > - both Rakesh and I have demonstrated that PSD is much more straightforwa= rd > for direct export, and it is possible to align nicely with the base > direct > export RFC. We don't miss bits here and there, we don't need to use > two LSEs > for the sequence number optional filed, we don't need to map > extension flags > from 8 bits to 6 bits. This is a case two situation. PSD would be > better. > > - it has earlier demonstrated that 19 octets worth of mutable data as ISD= , > personally I believe that that is a too serious limit, since to my > understanding > you for example you typically need at least 8 octets for a timestamp. > This is > mutable data, so you can only put two timestamps in one packet. That > seems to > me to be a limitation that we can't live with. This is a case 3 > situation. > ISD can't solve m ore than 2 timestamps, PSD can. I'm not a an > expert in the > area, so I leave it to the experts to tell me if I'm right or wrong. > > - We also seen cases where adding "too much" ISD into the stack, gives > us label > stacks that are too deep. If you want to put two timestamp in as ISD, > you will > need to increase the label stack with 12 LSEs, which seem to > excessive. A case > 3 situation. > > Yeah, so we need PSD. Please poll the draft-jags-mpls-ps-mna-hdr for > working group > adoption. > > /Loa > > > > Den 2024-06-26 kl. 21:35, skrev Joel Halpern: > > Loa, you list three bullet points with three different results. > > However, what has been shown so far seems to correspond to your first > > case, which you state does not justify two solutions. Adopting a > > post-stack data solution before we decide we are in case three, or in > > case 2 and feel the tradeoff is right, seems premature. It may well > > be that the ps draft is the right starting point once we have agreed > > on the problems to be solved. Which is why I am trying to understand > > the motivations for Rakesh' iOAM dex draft. (I do think we need to > > support IOAM DEX.) > > > > Yours, > > > > Joel > > > > On 6/26/2024 3:30 PM, Loa Andersson wrote: > >> Jags, authors, chairs, working group, > >> > >> > >> I support making draft-jags-mpls-ps-mna-hdr a working group document. > >> > >> It has repeatedly been said by those who want ISD-solutions that > >> PSD-solutions ar not needed. > >> > >> I think this is a fundamentally flawed way of asking the question. > >> > >> - if we have a choice between two solutions and they are equally good > >> for all cases, then it makes sense to try to find consensus for > >> adopting > >> one of the solutions > >> - if we have a choice between two solutions there both solutions "can > >> do" all > >> cases, but there one is significantly better for one set of cases > >> and the > >> other is significantly better for the remaining cases, we should > >> cases we > >> should seriously consider going for two solutions. > >> - if we we have the a choice between two solutions there one can > >> solve part of > >> the cases and the other the remaining cases, the we need to go for t= wo > >> solutions. > >> > >> /Loa > >> > >> > >> Den 2024-06-26 kl. 04:50, skrev Jaganbabu Rajamanickam (jrajaman): > >>> > >>> Hello Chairs, > >>> > >>> We would like to request WG adoption for draft-jags-mpls-ps-mna-hd= r. > >>> > >>> 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 > >> > > -- > Loa Andersson > Senior MPLS Expert > Bronze Dragon Consulting > loa@pi.nu > loa.pi.nu.@gmail.com > > _______________________________________________ > mpls mailing list -- mpls@ietf.org > To unsubscribe send an email to mpls-leave@ietf.org > --000000000000d8a3b5061bdf117e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Loa,
thank you for s= haring your opinion. I do agree that mutability of IOAM-DEX, as mutability = in general, is a restricting aspect in ECMP environments that use the label= stack information to generate entropy used in load-balancing. I read the l= atest version of the draft and have several questions on it and your notes:=
  • You mention timestamp in connection with IOAM-DEX. Could= =C2=A0you please point out to me where and how a timestamp information is u= sed in RFC 9326,= =C2=A0= draft-mb-mpls-ioam-dex, or=C2=A0draft-jags-mpls-ps-mna-hdr?
  • A= s I understand=C2=A0R= FC 9326, the Sequence Number is optional and is not used for Loss Measu= rement but, in combination with the Flow ID, help correlating telemetry inf= ormation generated by the same packet equipped with the IOAM-DEX. In your o= pinion, how large space is useful for the Sequence Number for the purpose d= escribed in=C2=A0RFC = 9326?
  • And a more general question. How=C2=A0draft-jags-mpls-ps-mn= a-hdr=C2=A0can be used in RLD-limited environment?
Regard= s,
Greg

<= /div>

On Thu, Jun 27, 2024 at 3:11=E2=80=AFAM Loa Andersson <loa@pi.nu> wrote:
Joel, wg, wg-chairs,

No I don't think we are in the first case, ISD and PSD is not equally g= ood
for all cases.

- both Rakesh and I have demonstrated that PSD is much more straightforward=
=C2=A0=C2=A0 for direct export, and it is possible to align nicely with the= base
direct
=C2=A0=C2=A0 export RFC. We don't miss bits here and there, we don'= t need to use
two LSEs
=C2=A0=C2=A0 for the sequence number optional filed, we don't need to m= ap
extension flags
=C2=A0=C2=A0 from 8 bits to 6 bits. This is a case two situation. PSD would= be better.

- it has earlier demonstrated that 19 octets worth of mutable data as ISD,<= br> =C2=A0=C2=A0 personally I believe that that is a too serious limit, since t= o my
understanding
=C2=A0=C2=A0 you for example you typically need at least 8 octets for a tim= estamp.
This is
=C2=A0=C2=A0 mutable data, so you can only put two timestamps in one packet= . That
seems to
=C2=A0=C2=A0 me to be a limitation that we can't live with. This is a c= ase 3
situation.
=C2=A0=C2=A0 ISD can't solve m ore than 2 timestamps, PSD can. I'm = =C2=A0 not a an
expert in the
=C2=A0=C2=A0 area, so I leave it to the experts to tell me if I'm right= or wrong.

- We also seen cases where adding "too much" ISD into the stack, = gives
us label
=C2=A0=C2=A0 stacks that are too deep. If you want to put two timestamp in = as ISD,
you will
=C2=A0=C2=A0 need to increase the label stack with 12 LSEs, which seem to <= br> excessive. A case
=C2=A0=C2=A0 3 situation.

Yeah, so we need PSD. Please poll the draft-jags-mpls-ps-mna-hdr for
working group
adoption.

/Loa



Den 2024-06-26 kl. 21:35, skrev Joel Halpern:
> Loa, you list three bullet points with three different results.
> However, what has been shown so far seems to correspond to your first =
> case, which you state does not justify two solutions. Adopting a
> post-stack data solution before we decide we are in case three, or in =
> case 2 and feel the tradeoff is right, seems premature.=C2=A0=C2=A0 It= may well
> be that the ps draft is the right starting point once we have agreed <= br> > on the problems to be solved. Which is why I am trying to understand <= br> > the motivations for Rakesh' iOAM dex draft.=C2=A0 (I do think we n= eed to
> support IOAM DEX.)
>
> Yours,
>
> Joel
>
> On 6/26/2024 3:30 PM, Loa Andersson wrote:
>> Jags, authors, chairs, working group,
>>
>>
>> I support making draft-jags-mpls-ps-mna-hdr a working group docume= nt.
>>
>> It has repeatedly been said by those who want ISD-solutions that <= br> >> PSD-solutions ar not needed.
>>
>> I think this is a fundamentally flawed way of asking the question.=
>>
>> - if we have a choice between two solutions and they are equally g= ood
>> =C2=A0 for all cases, then it makes sense to try to find consensus= for
>> adopting
>> =C2=A0 one of the solutions
>> - if we have a choice between two solutions there both solutions &= quot;can
>> do" all
>> =C2=A0 cases, but there one is significantly better for one set of= cases
>> and the
>> =C2=A0 other is significantly better for the remaining cases, we s= hould
>> cases we
>> =C2=A0=C2=A0 should seriously consider going for two solutions. >> - if we we have the a choice between two solutions there one can <= br> >> solve part of
>> =C2=A0 the cases and the other the remaining cases, the we need to= go for two
>> =C2=A0 solutions.
>>
>> /Loa
>>
>>
>> Den 2024-06-26 kl. 04:50, skrev Jaganbabu Rajamanickam (jrajaman):=
>>>
>>> Hello Chairs,
>>>
>>> =C2=A0=C2=A0 We would like to request WG adoption for draft-ja= gs-mpls-ps-mna-hdr.
>>>
>>> =C2=A0=C2=A0 Updated the draft with the initial review comment= s and the latest
>>> MNA header format.
>>>
>>> =C2=A0 Welcome your review comments and suggestions.
>>>
>>> Thanx,
>>>
>>> Jags
>>>
>>>
>>> _______________________________________________
>>> 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

_______________________________________________
mpls mailing list -- mpl= s@ietf.org
To unsubscribe send an email to mpls-leave@ietf.org
--000000000000d8a3b5061bdf117e--