Re: [mpls] Concerns about ISD

Robert Raszuk <rraszuk@gmail.com> Fri, 06 May 2022 13:08 UTC

Return-Path: <rraszuk@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 A2133C159823 for <mpls@ietfa.amsl.com>; Fri, 6 May 2022 06:08:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=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 eXN0H9xKUv_Q for <mpls@ietfa.amsl.com>; Fri, 6 May 2022 06:08:20 -0700 (PDT)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 D871EC159826 for <mpls@ietf.org>; Fri, 6 May 2022 06:08:20 -0700 (PDT)
Received: by mail-qk1-x730.google.com with SMTP id z126so5820871qkb.2 for <mpls@ietf.org>; Fri, 06 May 2022 06:08:20 -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=42lyXv58dJOH8J9YOK3Y1a3t09AFOfeO00wesEF7r/s=; b=ccNhkjO0uFS2/Y4h0vUx2axajvN1QYsaWcxuM+AaE/IQQtDmDo8CyEytMz12hmZW5f O+C8O5e695frrJ3Rj4uTVX61giOp0pF9gKx0DQFoeGs951y6qLXaxupibq5U7kh7h7L9 LZaH8/1OzLEvMbz903DnGMLZETkWr1zca9QOWa9YI0eKbVluML1QGQA4yJuldHtmzfyc nozYY6x4RO3di2ICLVfflJPR0bfvvBh4CFNpjnBbMouq/FUhbOyD3FftgyZu8j/jrn6x FNM6fkVKh2yJpsGumO2UO6rg1SnfccgZnBkPFkiRTC1SiJbsitjo7FGgZNo7uwTfZ8Zi LSfw==
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=42lyXv58dJOH8J9YOK3Y1a3t09AFOfeO00wesEF7r/s=; b=UhxqMFiLquROOwNq93t0vWHTpaUMG2hh6UsS8NouPJtJRZILs9Nn0pzNV7tEJlOW8V RA06/5ALiXsZP23R2m8+9cB47iLaT9NE540a0h9yNSl+7AEnKb0U0b1CoKo+3GSJOenT ipmW5SzAX5AyvxB97qOUCNMTsXhO0TMmPlYe7F73s3FTqqaOtm4fHo3IWn4i8HrJmDJS zaQ3Pm+X5AZt7zaeBfzrneSgW6XqgGlOK3uax7kqiVPeIVpan8PKpg3/Bky0oZj9hIpV uGtYnpyT62bPnf4I6tb4v+Pcm8Xw0cR2RfHXbpPrTjk6fI/YOVX/YY3JxsRG2zoqcyVC o3Nw==
X-Gm-Message-State: AOAM531jL9b0ssPrz3PI86YwnlD6bBjAC9Jcjmqp5so2Li0mS6vYKbIO br5keCBZAMFQHSqfe+qa43AjWau8whba6HZTX0s=
X-Google-Smtp-Source: ABdhPJyqVS/RwGCFnjxjZpg5K58j41Hh9stbsGL7MWJZmUj+LHUQaxwLxrVaTyyUxm7wIZDgxtxle1/i1MWbEmygHRg=
X-Received: by 2002:a05:620a:424e:b0:67e:4c1b:baef with SMTP id w14-20020a05620a424e00b0067e4c1bbaefmr2274847qko.778.1651842499187; Fri, 06 May 2022 06:08:19 -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> <BY3PR05MB8081542AB2F78C730EBFFD22C7C29@BY3PR05MB8081.namprd05.prod.outlook.com> <3c2f35ed915547e396211222ec56b0b6@huawei.com>
In-Reply-To: <3c2f35ed915547e396211222ec56b0b6@huawei.com>
From: Robert Raszuk <rraszuk@gmail.com>
Date: Fri, 6 May 2022 15:08:07 +0200
Message-ID: <CA+b+ERnjXm8K0XHAPSL_Rvj-SQi8uf_SmzkJ+AQ92J0u-pE4FQ@mail.gmail.com>
To: Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>
Cc: John E Drake <jdrake@juniper.net>, mpls <mpls@ietf.org>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006398c505de578d37"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/BFukXH_NQ3uH7dsq8VDOEZu9Q-I>
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: Fri, 06 May 2022 13:08:24 -0000

Hi Tianran,

IMO your observation is very valid. We have two modes of executing
network actions.

Mode 1 - On each node packet traverses
Mode 2 - On selective nodes packet traverses

*Mode 1: *

For all network actions which are required to be executed on all nodes we
can use today:

a) BSID
b) Prefix-SID and flex-algo (you define as part of the algo what needs to
be executed).

Done.

*Mode 2:*

For selective execution of network actions on specific nodes you use the
proposal I provide - RAF.

- - -

*Comments: *

*[A]*

Mode 1 does not work in LDP networks. Should it ? I do not know. My feeling
is that we should just provide solution using domain wide labels to
simplify the deployments and leverage what is already deployed.

If someone provides a valid use case for LDP and if operators will back it
- then sure MNA has some reason to exit.

*[B] *

Tony asked what is someone is not using SR ? Well domian wide labels are
not really limited to segment routing. Also flex algo is not limited to
segment routing use cases.

If on the other hand the point was about packet steering then MNA does not
really provide that either. RAF can fill in that gap if someone wishes for
whatever reasons to not use SR-MPLS for TE purposes.

Kind regards,
Robert












On Fri, 6 May 2022 at 02:34, Tianran Zhou <zhoutianran=
40huawei.com@dmarc.ietf.org> wrote:

> Sure, obviously they are for different purposes.
>
> Can we combine multiple existing components for one goal?
>
> Say we have A and B, can we use A+B for something?
>
> Or we must create C to replace A+B?
>
>
>
> Tianran
>
>
>
> *From:* John E Drake [mailto:jdrake@juniper.net]
> *Sent:* Thursday, May 5, 2022 9:02 PM
> *To:* Tianran Zhou <zhoutianran@huawei.com>
> *Cc:* John E Drake <jdrake=40juniper.net@dmarc.ietf.org>rg>; Tony Li <
> tony.li@tony.li>gt;; mpls <mpls@ietf.org>
> *Subject:* RE: [mpls] Concerns about ISD
>
>
>
> BSID and NAS are for completely different purposes.  The former is for
> stack compression and the latter is for network actions.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Tianran Zhou <zhoutianran@huawei.com>
> *Sent:* Wednesday, May 4, 2022 8:43 PM
> *To:* John E Drake <jdrake@juniper.net>
> *Cc:* John E Drake <jdrake=40juniper.net@dmarc.ietf.org>rg>; Tony Li <
> tony.li@tony.li>gt;; mpls <mpls@ietf.org>
> *Subject:* RE: [mpls] Concerns about ISD
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi,
>
> 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.
>
>
>
> Tianran
>
>
>
> *From:* John E Drake [mailto:jdrake@juniper.net <jdrake@juniper.net>]
> *Sent:* Saturday, April 30, 2022 12:05 AM
> *To:* Tianran Zhou <zhoutianran@huawei.com>
> *Cc:* John E Drake <jdrake=40juniper.net@dmarc.ietf.org>rg>; Tony Li <
> tony.li@tony.li>gt;; mpls <mpls@ietf.org>
> *Subject:* Re: [mpls] Concerns about ISD
>
>
>
> Comment inline
>
> Sent from my iPhone
>
>
>
> On Apr 29, 2022, at 11:17 AM, Tianran Zhou <zhoutianran@huawei.com> wrote:
>
> 
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi,
> Comments inline.
>
> Tianran
>
>
>
> >
> > Hi John,
> >
> >  If we want to reuse this for consistent design (easy for interop), how
> do you
> > want to encode it to ISD?
> >
> > [JD]  That's up to a given solution to propose, but probably two LSEs
> >
> > ZTR> It would be interesting to know your proposal.
>
> [JD]  As I said, the size of an NRP ID needs to be decided and any MNA
> solution needs propose how it is to be
> encoded
>
> ZTR> Ok, so any solution need to demonstrate how it works.
>
>
> >
> >
> > 2. If we really worry about the MSD of SR, why not use BSID as a direct
> way to
> > reduce the stack?
> >
> > [JD]  Because it can't be mandated
> >
> > ZTR> I am sorry, I do not understand why BSID is not applicable. What's
> the "
> > mandated " mean here?
>
> [JD]  MNA cannot require the use of BSIDs
>
>
> ZTR> Is this an agreed requirement? In the requirement draft? I still
> can’t understand. On one hand, you worry about low stack depth. On the
> other hand, you don’t want to use an easy way to solve this problem.
>
> [JD]  I don’t think it’s realistic to tell a network operator that they
> have to deploy BSID in order to deploy MNA.  Also, I don’t think it’s a
> good solution became a label stack of BSIDs may still be too large and the
> node advertising the BSID is going to expand the the label stack with the
> path SIDS so the nodes on the path will have to deal with a large label
> stack.
>
>
>
>
> >
> > Tianran
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>