Re: [mpls] Concerns about ISD

Tianran Zhou <zhoutianran@huawei.com> Sat, 07 May 2022 07:49 UTC

Return-Path: <zhoutianran@huawei.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 33BD5C15E3F6 for <mpls@ietfa.amsl.com>; Sat, 7 May 2022 00:49:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 T28OCWVVdbVY for <mpls@ietfa.amsl.com>; Sat, 7 May 2022 00:49:54 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05EC2C15E3EC for <mpls@ietf.org>; Sat, 7 May 2022 00:49:54 -0700 (PDT)
Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KwKJD007jz67M1h; Sat, 7 May 2022 15:46:35 +0800 (CST)
Received: from kwepemi100009.china.huawei.com (7.221.188.242) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 7 May 2022 09:49:49 +0200
Received: from kwepemi500009.china.huawei.com (7.221.188.199) by kwepemi100009.china.huawei.com (7.221.188.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 7 May 2022 15:49:47 +0800
Received: from kwepemi500009.china.huawei.com ([7.221.188.199]) by kwepemi500009.china.huawei.com ([7.221.188.199]) with mapi id 15.01.2375.024; Sat, 7 May 2022 15:49:47 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Robert Raszuk <rraszuk@gmail.com>
CC: John E Drake <jdrake@juniper.net>, mpls <mpls@ietf.org>, John E Drake <jdrake@juniper.net>
Thread-Topic: [mpls] Concerns about ISD
Thread-Index: AdhKc4fdvDv9lzMNTfy5c++8iNI9i///poSA//7GfeCAAt4vgP/7wPiAgAhY2QD//2GkAAAn72wA//7TxPD//eE1gP/7NOOg//aGzID/67yBQP/A47NQ/4IVBQD/AoIJwP4FIVMA/Ajye8D4EaIJgPAiknoV4EWd0IDAgkrxQIEES7sAggdRh+CEDlTigIga6o4Q
Date: Sat, 07 May 2022 07:49:47 +0000
Message-ID: <bca09bbc01304368a8bbac4d45682a32@huawei.com>
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> <CA+b+ERnjXm8K0XHAPSL_Rvj-SQi8uf_SmzkJ+AQ92J0u-pE4FQ@mail.gmail.com>
In-Reply-To: <CA+b+ERnjXm8K0XHAPSL_Rvj-SQi8uf_SmzkJ+AQ92J0u-pE4FQ@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.195]
Content-Type: multipart/alternative; boundary="_000_bca09bbc01304368a8bbac4d45682a32huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/BWy6BleVqUuHLX1H0SrvESofEak>
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: Sat, 07 May 2022 07:49:59 -0000

Hi Robert,

Thanks for this proposal.
I like it.

Tianran

From: Robert Raszuk [mailto:rraszuk@gmail.com]
Sent: Friday, May 6, 2022 9:08 PM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: John E Drake <jdrake@juniper.net>; mpls <mpls@ietf.org>; John E Drake <jdrake@juniper.net>
Subject: Re: [mpls] Concerns about ISD

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<mailto: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<mailto:jdrake@juniper.net>]
Sent: Thursday, May 5, 2022 9:02 PM
To: Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>
Cc: John E Drake <jdrake=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>>; Tony Li <tony.li@tony.li<mailto:tony.li@tony.li>>; mpls <mpls@ietf.org<mailto: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<mailto:zhoutianran@huawei.com>>
Sent: Wednesday, May 4, 2022 8:43 PM
To: John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>
Cc: John E Drake <jdrake=40juniper.net@dmarc.ietf.org<mailto:jdrake=40juniper.net@dmarc.ietf.org>>; Tony Li <tony.li@tony.li<mailto:tony.li@tony.li>>; mpls <mpls@ietf.org<mailto: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]
Sent: Saturday, April 30, 2022 12:05 AM
To: Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>
Cc: John E Drake <jdrake=40juniper.net@dmarc.ietf.org<mailto:jdrake=40juniper.net@dmarc.ietf.org>>; Tony Li <tony.li@tony.li<mailto:tony.li@tony.li>>; mpls <mpls@ietf.org<mailto: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<mailto: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<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls