Re: [mpls] Comments on draft-andersson-mpls-mna-fwk-01

"Dongjie (Jimmy)" <jie.dong@huawei.com> Mon, 30 May 2022 10:35 UTC

Return-Path: <jie.dong@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 04486C15BFFA; Mon, 30 May 2022 03:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 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, T_SCC_BODY_TEXT_LINE=-0.01, 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 7QrUWDsuZ_3i; Mon, 30 May 2022 03:35:17 -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 29B20C15BFFF; Mon, 30 May 2022 03:35:17 -0700 (PDT)
Received: from fraeml742-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LBWtL47Pcz6855X; Mon, 30 May 2022 18:31:54 +0800 (CST)
Received: from kwepemi500015.china.huawei.com (7.221.188.92) by fraeml742-chm.china.huawei.com (10.206.15.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 30 May 2022 12:35:13 +0200
Received: from kwepemi500017.china.huawei.com (7.221.188.110) by kwepemi500015.china.huawei.com (7.221.188.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 30 May 2022 18:35:12 +0800
Received: from kwepemi500017.china.huawei.com ([7.221.188.110]) by kwepemi500017.china.huawei.com ([7.221.188.110]) with mapi id 15.01.2375.024; Mon, 30 May 2022 18:35:12 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: Tony Li <tony.li@tony.li>, "draft-andersson-mpls-mna-fwk@ietf.org" <draft-andersson-mpls-mna-fwk@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: [mpls] Comments on draft-andersson-mpls-mna-fwk-01
Thread-Index: AdhwQrdhXtvtRdIrQNeDk8wXTg4yFAAo0kUAAC4bcJAAOJzwAABiFAuw
Date: Mon, 30 May 2022 10:35:12 +0000
Message-ID: <cd3934b42ad8468eb617939e46328c8c@huawei.com>
References: <2a6db1c68e594c3082349733b32df351@huawei.com> <4204F6A9-5D62-4A3C-846E-4FB323B8A05E@tony.li> <3a37f2ab48924f059451f7f55317c74b@huawei.com> <CA+RyBmV5a4vk=Li-qsz=CRDozm1rL_vWVkwkd7Kr0qC8b6WfDw@mail.gmail.com>
In-Reply-To: <CA+RyBmV5a4vk=Li-qsz=CRDozm1rL_vWVkwkd7Kr0qC8b6WfDw@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.85.147.18]
Content-Type: multipart/alternative; boundary="_000_cd3934b42ad8468eb617939e46328c8chuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/mDC9vP6ikGldAbO-TUxRLvak8ZU>
Subject: Re: [mpls] Comments on draft-andersson-mpls-mna-fwk-01
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: Mon, 30 May 2022 10:35:22 -0000

Hi Greg,

Thanks for providing your opinion on this.

The recent discussion in the open DT meeting I recall was not about whether ISD is viable or not, but whether it is really needed in the framework considering that PSD is needed anyway. Thus as suggested further analysis based on the use cases is needed to validate the candidate solutions (ISD+PSD, ISD only, PSD only). The result of the analysis could be used to guide the development of the framework. This was the approach used by the SRv6 compression DT.

As an open DT participant my job is to provide review comments to the DT related work for the draft authors to consider, at the individual draft stage it is up to the authors to make change or not.

Best regards,
Jie

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Sunday, May 29, 2022 2:51 AM
To: Dongjie (Jimmy) <jie.dong@huawei.com>
Cc: Tony Li <tony.li@tony.li>li>; draft-andersson-mpls-mna-fwk@ietf.org; mpls@ietf.org
Subject: Re: [mpls] Comments on draft-andersson-mpls-mna-fwk-01

Hi Jimmy,
I want to share my views on the question of ISD and what we can interpret as "consensus".
As I've commented before, ISD is a viable and useful option and I don't see a good technical reason to not include it in the MNA architecture. Whether this view is where the WG consensus falls, I don't know. I believe that is the prerogative of the WG Chairs to determine that. As for the authors of this individual draft, I believe they are not obligated to change their document unless they want that.

Regards,
Greg

On Sat, May 28, 2022 at 1:22 AM Dongjie (Jimmy) <jie.dong=40huawei.com@dmarc.ietf.org<mailto:40huawei.com@dmarc.ietf.org>> wrote:
Hi Tony,

Thanks for your prompt reply, and the effort of making some changes in the updated version.

The remaining comments I see are mainly about the following aspects:


1.      Concepts and terminologies


-        Network Action vs forwarding action. Since this document introduces the concept “network actions”, and it says network action is more general than forwarding action, I’m not sure the concept “forwarding action” needs to be defined here, actually it is only mentioned in the introduction. I’d suggest to just introduce one new concept (network action) instead of two.


-        Ancillary data. The major question is: are the network actions without further parameters considered as ancillary data? This was recorded as one of the comments to the requirement document, and this document shows that inconsistency understanding of this basic concept could result in different interpretation of other terminologies. Thus I’d suggest the DT and the WG to have further review and discussion about the definition and the scope of ancillary data.



-        Network Action Sub-stack Indicator (NSI) and MNA label. These terms are used to refer to the indicator of the network action sub-stack. However, there is no clear text about whether they can indicate the existence of PSD or not. In the framework a general term for the indicator of the ancillary data (either ISD or PSD) is needed.


2.      Considerations about ISD and PSD in the framework



According to the recent DT and mail list discussion, it seems the consensus is that the framework and solution need to include the mechanism for carrying PSD. Whether ISD is needed in the framework and the specific solutions is still under discussion. Thus it is suggested the framework document align with the DT’s discussion on this point: have some text to indicate that PSD is the necessary component of the framework. For the text about ISD, it is suggested to indicate ISD is an optional component, and for some solutions ISD may not be used.



3.      Changes to MPLS forwarding/processing

The potential changes introduced by MNA to MPLS architecture is not only in the data plane encoding, but also in the forwarding and processing behaviors. This is especially the case for the processing of the ISD data. IMO this is one of the most important things the framework should cover. There is a placeholder section on the development of MPLS forwarding model, the processing of the indicator, the ISD and/or PSD data based on MPLS forwarding model needs to be specified.


4.      Incorporation of related existing work



One of the comments I made is that draft-song-mpls-eh-indicator describes the alternatives of the indicator of the extension header. Please note that most of that text is about general analysis and comparison, and is not specific to any solution (i.e. not PSD only). Thus incorporation of such text would be helpful to this framework document.



Another existing work which may be incorporated is draft-andersson-mpls-eh-architecture, which describes the architecture of MPLS extension header. Some of the text in that document may be reused for the description of the PSD part, and some text may even be generic for both ISD and PSD.


Hope this helps.

Best regards,
Jie

From: Tony Li [mailto:tony1athome@gmail.com<mailto:tony1athome@gmail.com>] On Behalf Of Tony Li
Sent: Friday, May 27, 2022 1:50 AM
To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>
Cc: draft-andersson-mpls-mna-fwk@ietf.org<mailto:draft-andersson-mpls-mna-fwk@ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org>
Subject: Re: Comments on draft-andersson-mpls-mna-fwk-01


Hi Jimmy,

Thank you for your comments.  I’ve replied to each and every one of them.  As you commented inside of a Word document, I’ve replied in kind.  Please see the attached document.

I have made a number of the changes that you’ve suggested.  I will send a separate post to the list with the updated document and a diff.

Many of the changes that you suggested hinge on a single question which you did not raise directly.  That question should have the input of the broader group, so I’ll raise it explicitly now:

        Currently the framework document implicitly precludes some of the mechanisms found in draft-song-mpls-eh-indicator.
        Should the framework draft be broadened to encompass this draft?

Speaking personally (co-author hat off), I don’t see an architectural reason to disagree. Please don’t take this as support of the draft.  I still believe that this is a sub-optimal approach, but could it work architecturally?  I have to say that yes, it could, and thus the framework draft could and should be broadened to encompass this.

If the group agrees with this, the changes to implement this are minimal and straightforward.

Could I please get input from the group?

Regards,
Tony


> On May 25, 2022, at 7:34 AM, Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>> wrote:
>
> Dear authors,
>
> Thanks for the effort in organizing and updating this document. I've reviewed the current version and have a number of comments and suggestions.
>
> In my view, the most important thing for this framework document is to describe the possible changes introduced to the MPLS architecture, the MPLS data plane encoding, and the processing behaviors of the LSRs.
>
> Please find the attached file for the details of my review notes.
>
> Hope it helps and looking forward to your feedback.
>
> Best regards,
> Jie
> <draft-andersson-mpls-mna-fwk-01_Jie Dong_0525.docx>
_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls