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 3529FC15154E; Wed, 26 Jun 2024 16:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 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] 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 HdE0SztCAlGm; Wed, 26 Jun 2024 16:41:14 -0700 (PDT) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 8C192C151545; Wed, 26 Jun 2024 16:41:14 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id 3f1490d57ef6-e02eb6f06d8so5068982276.2; Wed, 26 Jun 2024 16:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719445273; x=1720050073; 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=JjVf+DIyMG9egYi9/mqlHyP1cqDdnNw6c6ClRyE9TM0=; b=HWlcUE6Az+ylY3djQJsf6XvMm6e8aqARih5z8bWdXQE8msSitUTRBqMX34qGMlzx/g A+TBOKxa/2oOViPvSM/+zNKP8h+j0wah4uNWKPgaHCTv/hp7sbsGycnBB3bzpX5VO/+s He8fR57LtXbW0dW82KRzHT4wS8E/vfcZZ+hEmBkFntd25vMFlwEAYuJACNaF0SycXkfM 91ymp9bSE3zVtc0nMIedxqRlILF4hqB7Oal7JdDyB4qhcL1G77s6k/GAjnuh5RkqJKr/ PSsA6SHpHWPRCTPa3dcj7LICdeYisGgq/g6SHtX+dTphNCQJ5HSlonueOrAZAgZr1yGE mSEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719445273; x=1720050073; 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=JjVf+DIyMG9egYi9/mqlHyP1cqDdnNw6c6ClRyE9TM0=; b=oaL+j6hwIwJoveoKTUe1s0YU2ONvOkb6u3wZJyu4V65dldhebPmT4e2IkCujJnL+/X MqTLKZX4SJwvPr9ziAlkhfIYn0s7f6Cw0FjUJVVPHTYpkdy54ABqG4ShFXowpywBxB0h Ie8MGfpyJ3CB7HlmAz1roP4rlNVwWElMLzsyYPN0U0XHNooihyX7j0h9gCmJBmhKWqCg SE1L9Fxic3srSvSlkCyDMhR9IuLrhtbFtufrZWeOZ2LhtP+dSvAXa0aPqWK0Yepv1o3m ZMySXjdZQPmLoDPem9BymoyTaCh4K9J6OwKqXNOmLLVH7kY+OoiQRUCxb/wjZrGoO/8I boRQ== X-Forwarded-Encrypted: i=1; AJvYcCVVVm83ykxModbVDepg9ZHpMgLB/y+y7xhWdtlA8LbPZuY2pdCe05f/03LSX094US1MwUKQexejjawlgen63fP0ngxG+RpdpZzQZncOmA60sN/n4112I6DNGExSjb8bsbgxhw== X-Gm-Message-State: AOJu0YwoKfGMZNc5vvRXUiNXLN3ZbtlBcZCnNUC4mlEk4/u9FVig6+MD tx2Hs+C5pb3LE0BRd2lTiDdO7Xnxel5gcZ9Tn44K22h8Xksbi2ZYlto3s5czTmncmMWx8rxc+Ic 9tOxD2rO1qp5EsRrA6unwPkn7pkg= X-Google-Smtp-Source: AGHT+IGT1yl/cFwOeLWq3IQ4ySWD9mKnWZuZS/EfKL7ePkQPgrLC9wYpw8tZBFV3xRyGhLbA3rKGZWXkUC5N9WRGBwQ= X-Received: by 2002:a25:ef50:0:b0:dfd:b3bb:ac11 with SMTP id 3f1490d57ef6-e034555d425mr467091276.59.1719445273494; Wed, 26 Jun 2024 16:41:13 -0700 (PDT) MIME-Version: 1.0 References: <20fade0a-e70a-4e62-a9d3-504e29940843@pi.nu> <7c285cf9-8f6c-4a57-b340-77e0772bef9b@joelhalpern.com> In-Reply-To: From: Greg Mirsky Date: Wed, 26 Jun 2024 16:41:03 -0700 Message-ID: To: Haoyu Song Content-Type: multipart/alternative; boundary="000000000000bccee6061bd38c7e" Message-ID-Hash: HZ52WCQ3YGTXNRFCBYO6PXJGKO2YVEHX X-Message-ID-Hash: HZ52WCQ3YGTXNRFCBYO6PXJGKO2YVEHX 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: --000000000000bccee6061bd38c7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Haoyu, I find the argument "We don't care about your problem" unusual for an environment striving to reach, although rough, consensus nevertheless. MSD is a well-known network constraint that, I suspect, would not go away very soon (similar to using the label stack to generate entropy in the ECMP environment). MSD is real, and we must consider it when making design decisions. I don't think that operators will look favorably at a technology that requires the forklift upgrade of a network. Regards, Greg On Wed, Jun 26, 2024 at 4:31=E2=80=AFPM Haoyu Song wrote: > Greg, > > A feature having severe performance impact to one device doesn=E2=80=99t > necessarily mean it has the same issue to others=E2=80=99 devices. Also, = not > everyone must implement it. It=E2=80=99s all about user=E2=80=99s prefere= nce, capability, > and choice. > > > > Best, > > Haoyu > > *From:* Greg Mirsky > *Sent:* Wednesday, June 26, 2024 1:06 PM > *To:* Haoyu Song > *Cc:* Joel Halpern ; Loa Andersson ; mpls > ; draft-jags-mpls-ps-mna-hdr@ietf.org > *Subject:* Re: [mpls] Re: Request WG adoption for > draft-jags-mpls-ps-mna-hdr-03.txt > > > > Hi Haoyu, > > I am surprised that the proponents of PSD-based solution use limited > impact on the MPLS label stack depth as an argument while seemingly > ignoring the MSD issue that, in my opinion, might have more severe impact > on degrading the forwarding performance of the already deployed networkin= g > devices. > > > > Regards, > > Greg > > > > On Wed, Jun 26, 2024 at 12:59=E2=80=AFPM Haoyu Song > wrote: > > Hi Joel, > > I think it's important to support IOAM DEX as specified in RFC9326. I > don't think it can still be called IOAM DEX if the header format is chang= ed > in order to fit it in ISD. As Rakesh has explained, the header itself is > extensible, and the header size is large with options. Both these make it > unsuitable for ISD. > > Best, > Haoyu > > -----Original Message----- > From: Joel Halpern > Sent: Wednesday, June 26, 2024 12:35 PM > To: Loa Andersson ; mpls ; > draft-jags-mpls-ps-mna-hdr@ietf.org > Subject: [mpls] Re: Request WG adoption for > draft-jags-mpls-ps-mna-hdr-03.txt > > 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 d= ex > 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 tw= o > > 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-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 to mpls-leave@ietf.org > _______________________________________________ > mpls mailing list -- mpls@ietf.org > To unsubscribe send an email to mpls-leave@ietf.org > > --000000000000bccee6061bd38c7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Haoyu,
I find the argument "We don't care about your problem" unusu= al for an environment striving to reach, although rough, consensus neverthe= less. MSD is a well-known network constraint that, I suspect, would not go = away very soon (similar to using the label stack to generate entropy in the= ECMP environment). MSD is real, and we must consider it when making design= decisions. I don't think that operators will look favorably at a techn= ology that requires the forklift upgrade of a network.

=
Regards,
Greg

On Wed, Jun 26, 2024 at 4:31= =E2=80=AFPM Haoyu Song <haoy= u.song@futurewei.com> wrote:

Greg,

A feature having severe performance impact to one de= vice doesn=E2=80=99t necessarily mean it has the same issue to others=E2=80= =99 devices. Also, not everyone must implement it. It=E2=80=99s all about u= ser=E2=80=99s preference, capability, and choice. =C2=A0=C2=A0

=C2=A0

Best,

Haoyu

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Wednesday, June 26, 2024 1:06 PM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Joel Halpern <jmh@joelhalpern.com>; Loa Andersson <loa@pi.nu>; mpls <mpls@ietf.org>; draft-jags-mpls-ps-= mna-hdr@ietf.org
Subject: Re: [mpls] Re: Request WG adoption for draft-jags-mpls-ps-m= na-hdr-03.txt

=C2=A0

Hi Haoyu,

I am surprised that the proponents of PSD-based solu= tion use limited impact on the MPLS label stack depth as an argument while = seemingly ignoring the MSD issue that, in my opinion, might have more sever= e impact on degrading the forwarding performance of the already deployed networking devices.

=C2=A0

Regards,

Greg

=C2=A0

On Wed, Jun 26, 2024 at 12:59=E2=80=AFPM Haoyu Song = <haoyu.son= g@futurewei.com> wrote:

Hi Joel,

I think it's important to support IOAM DEX as specified in RFC9326. I d= on't think it can still be called IOAM DEX if the header format is chan= ged in order to fit it in ISD.=C2=A0 As Rakesh has explained, the header it= self is extensible, and the header size is large with options. Both these make it unsuitable for ISD.

Best,
Haoyu

-----Original Message-----
From: Joel Halpern <jmh@joelhalpern.com>
Sent: Wednesday, June 26, 2024 12:35 PM
To: Loa Andersson <loa@pi= .nu>; mpls <mp= ls@ietf.org>; dr= aft-jags-mpls-ps-mna-hdr@ietf.org
Subject: [mpls] Re: Request WG adoption for draft-jags-mpls-ps-mna-hdr-03.t= xt

Loa, you list three bullet points with three different results. However, wh= at 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 b= efore 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 a= greed on the problems to be solved. Which is why I am trying to understand = the motivations for Rakesh' iOAM dex draft.=C2=A0 (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.<= br> >
> 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<= br> > =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 "= ;can
> do" all
> =C2=A0 cases, but there one is significantly better for one set of cas= es
> and the
> =C2=A0 other is significantly better for the remaining cases, we shoul= d
> 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 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-jags-m= pls-ps-mna-hdr.
>>
>> =C2=A0=C2=A0 Updated the draft with the initial review comments an= d 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
>

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

--000000000000bccee6061bd38c7e--