IETF Logo Mail Archive

Re: [mpls] Concerns about ISD

Greg Mirsky <gregimirsky@gmail.com> Thu, 05 May 2022 19:24 UTC

Return-Path: <gregimirsky@gmail.com>
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 2AFD8C1594BF for <mpls@ietfa.amsl.com>; Thu, 5 May 2022 12:24:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.095
X-Spam-Level:
X-Spam-Status: No, score=-1.095 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 g3rJASkMxstL for <mpls@ietfa.amsl.com>; Thu, 5 May 2022 12:24:47 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 6C12CC15949C for <mpls@ietf.org>; Thu, 5 May 2022 12:24:47 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id t25so9072059lfg.7 for <mpls@ietf.org>; Thu, 05 May 2022 12:24:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GBhzkI9LRfidDoqegV13UlGjL8YVbNwiQFvDlFxcdro=; b=dLOZqybwhoU4BBmaat53XyBwxnoAXJC2qIF8y9IJ1PApAgR1bxL8fnPgLhNHpGcR6S SyzqZNUfABitjbvuzFkEKBot2yktHWEuBMYgh7mexWoYn7wpQ+CdeIrIqiJMnlYMus2Z P3E18fjxlknL0i5+xmJcy8aHpRK6d0khM+tIp8dofD45UWqHjr1aidfLGZ6GtY6F7REy IXNw8bi6jVp23zE2P1NYiFUUcmjKq6QzcLUIyuwEFj4CDzhEGi3vLr7or2xBAkN3eqyk 8Yjog0QdSiS1eMeKze7NE9neDWYF4brD/vLhC7i+aWoxdR9HVeD8BW2zL+qW/ebaBqPD edYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GBhzkI9LRfidDoqegV13UlGjL8YVbNwiQFvDlFxcdro=; b=uKq/o/xSnzbQBMR/s4FYn42xkIjueAauZXxWrTNSbWMRDvwxylFBl267/w50RPO0ja k1lMW+f7an51gY1SWU7pAMDYH0VFnB4MpsCxYnYUgAseVWqgzGBxro5QhIkPQd5Ey7jS 8qgz1lTn61g9mdXURuaz1T5DGkvWCsoM7YGMxSOJEjtBj2Hl1bLkMsuqiMD3ItauLgqQ 00FQgwGqXO/Y95mB4h9Bg1+MlybQ96HzgyfZp1DOSZoQsujiEN4D8gx8xKWijAva661U JmWKno005QtakGmmX2qonaPehoEIIytFXB9oR2dZvxX1aWWTSk3yFeY/4OYc18Y0e1f9 IDtQ==
X-Gm-Message-State: AOAM530MppO1i4K3ZXSx4vH5bjQU2F4V9BEdmHFjFgkdFWPHPvq8F5Uq ufClqcwflUq1yzXvt6nKT30saMIx8ijDRzxYu8fDCF63
X-Google-Smtp-Source: ABdhPJwaFqK7P7kxINpXZC2z4BKI8sTbWAwV+50mRIfGqNE7/V8HAJfKC6mKoD0Hux86NTkZ42DsEar89vNpn/u3T0I=
X-Received: by 2002:a05:6512:3ee:b0:471:f84f:7d5b with SMTP id n14-20020a05651203ee00b00471f84f7d5bmr18329146lfq.18.1651778684846; Thu, 05 May 2022 12:24:44 -0700 (PDT)
MIME-Version: 1.0
References: <6cc272447d2f4c779e85d5c42d3b3c6c@huawei.com> <8623637D-A32E-47A4-B5FC-4D2CF40BEDD1@tony.li> <6199e0e886f9437c95ef9b70719b00ec@huawei.com> <BCFD3F4A-36D6-47C2-B907-FC40B402F97C@tony.li> <3fb1f261ddff48deb0c2ea083cdbd16f@huawei.com> <6B96F21B-9331-4FA8-AD7B-84A4CA8B6FAB@tony.li> <903c57a48280454091495673ec2fe275@huawei.com> <BD5C1BE7-4633-4B51-BAC1-B2AE1C537F36@tony.li> <ad6b8c42b0aa4880b9dee02516f5e46f@huawei.com> <F5BB2CEB-CC8C-4E71-A2E7-B4212878C3B1@tony.li> <aa9c4b913d844410b2af90c8db78c194@huawei.com> <BY3PR05MB8081937B52E657713E8293BFC7ED9@BY3PR05MB8081.namprd05.prod.outlook.com> <a29c96be774845e582a66700d2264f7b@huawei.com> <e986565c98c24cadb858ca4abf6dbbfb@huawei.com> <BY3PR05MB8081A6A725740415356DB2EBC7FA9@BY3PR05MB8081.namprd05.prod.outlook.com> <eb8d7858982d449e94511f81eb9913c8@huawei.com> <BY3PR05MB808117E628EC6487362E6275C7FD9@BY3PR05MB8081.namprd05.prod.outlook.com> <ded09bb6ec864465982f5e025937c8e0@huawei.com> <BY3PR05MB80817C746EF6621F80730082C7FC9@BY3PR05MB8081.namprd05.prod.outlook.com> <41561193f7d448ff96129d6da20e49a2@huawei.com> <535C336B-545F-4E0E-A9DF-990FC0AB53CC@juniper.net> <d3c84493e63648ffaa6c902712c0739e@huawei.com> <DD62DC4D-C858-436C-B4A7-91A31F1DD0E8@tony.li> <5882db0f905847859d9973316bea3c85@huawei.com>
In-Reply-To: <5882db0f905847859d9973316bea3c85@huawei.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 05 May 2022 12:24:32 -0700
Message-ID: <CA+RyBmWx+8Af7DRWnh_KOMWePBam+nfN_HRW0UPBNChpzU+9Lw@mail.gmail.com>
To: Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>
Cc: Tony Li <tony.li@tony.li>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, mpls <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c205cd05de48b1ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/D5XnlVqR6V2v8GvPGPbV1eNyUUM>
Subject: Re: [mpls] Concerns about ISD
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 May 2022 19:24:51 -0000

Hi Tianran,
I think that IOAM's Pre-allocated or Incremental trace options for
hop-by-hop collection of the telemetry information present a use case that
overturns your assumption. Consider a scenario when multiple MNAs are
requested and IOAM is preceding some of the respective ancillary data
segments in PSD. The size of the IOAM data area can grow large and thus
making accessing other ancillary data very costly.

Regards,
Greg

On Wed, May 4, 2022 at 7:39 PM Tianran Zhou <zhoutianran=
40huawei.com@dmarc.ietf.org> wrote:

> Hi Tony,
>
>
>
> I think we have discussed the scenario before, sr or lsp.
>
> For normal lsp, the stack should not be too large. Hence no big difference
> from ISD and PSD. I.e, no space for optimization.
>
> So I think our context is only about sr.
>
>
>
> Best,
>
> Tianran
>
>
>
> *From:* Tony Li [mailto:tony1athome@gmail.com] *On Behalf Of *Tony Li
> *Sent:* Thursday, May 5, 2022 10:18 AM
> *To:* Tianran Zhou <zhoutianran@huawei.com>
> *Cc:* John E Drake <jdrake@juniper.net>; John E Drake <jdrake=
> 40juniper.net@dmarc.ietf.org>; mpls <mpls@ietf.org>
> *Subject:* Re: [mpls] Concerns about ISD
>
>
>
>
>
>
>
> On May 4, 2022, at 5:42 PM, Tianran Zhou <zhoutianran@huawei.com> wrote:
>
>
>
> It does not make sense to me to create a new mechanism as ISD in
> operators’ network, while not using existing mature BSID.
>
> There is no sign the reinvented wheel could be better.
>
>
>
>
>
> Hi Tianran,
>
>
>
> BSID assumes that SR is in use.  What if it isn’t?
>
>
>
> Tony
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>

v2.23.0 | Report a Bug | By Email