[mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr

Tianran Zhou <zhoutianran@huawei.com> Thu, 06 June 2024 00:25 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 7E8E7C151983; Wed, 5 Jun 2024 17:25:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level:
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=unavailable 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 kTAO3Df1xrXb; Wed, 5 Jun 2024 17:25:36 -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 D889BC14F6BA; Wed, 5 Jun 2024 17:25:35 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VvlSj26PSz6K9RV; Thu, 6 Jun 2024 08:24:21 +0800 (CST)
Received: from lhrpeml100005.china.huawei.com (unknown [7.191.160.25]) by mail.maildlp.com (Postfix) with ESMTPS id E86B51408F9; Thu, 6 Jun 2024 08:25:32 +0800 (CST)
Received: from dggpemf100009.china.huawei.com (7.185.36.128) by lhrpeml100005.china.huawei.com (7.191.160.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 6 Jun 2024 01:25:31 +0100
Received: from kwepemf100007.china.huawei.com (7.202.181.221) by dggpemf100009.china.huawei.com (7.185.36.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 6 Jun 2024 08:25:28 +0800
Received: from kwepemf100007.china.huawei.com ([7.202.181.221]) by kwepemf100007.china.huawei.com ([7.202.181.221]) with mapi id 15.02.1544.011; Thu, 6 Jun 2024 08:25:28 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: "Jaganbabu Rajamanickam (jrajaman)" <jrajaman=40cisco.com@dmarc.ietf.org>, Joel Halpern <jmh@joelhalpern.com>, "je_drake@yahoo.com" <je_drake@yahoo.com>
Thread-Topic: [mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr
Thread-Index: AQHatiiIbL2kXbzkPE2hd/zXdq/237G28WcQgAAkkwCAALCP2f//f/YAgAFRuYCAAAbKgIABQufA
Date: Thu, 06 Jun 2024 00:25:28 +0000
Message-ID: <25024a7f878d44088b7070ba7da14702@huawei.com>
References: <E4B10F7A-6E4D-46DC-9830-11FF7FD14307@yahoo.com> <db508e17-d107-4cb0-832c-998a2a1b8131@joelhalpern.com> <MN2PR11MB406448E4033A385D9BF0661ED0F92@MN2PR11MB4064.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB406448E4033A385D9BF0661ED0F92@MN2PR11MB4064.namprd11.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.118]
Content-Type: multipart/related; boundary="_004_25024a7f878d44088b7070ba7da14702huaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
Message-ID-Hash: M7TJ4G7OYGKKH4QAASDYPDONVMSZ3OKK
X-Message-ID-Hash: M7TJ4G7OYGKKH4QAASDYPDONVMSZ3OKK
X-MailFrom: zhoutianran@huawei.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@ietf.org" <mpls@ietf.org>, MPLS Working Chairs <mpls-chairs@ietf.org>, "draft-ietf-mpls-mna-hdr@ietf.org" <draft-ietf-mpls-mna-hdr@ietf.org>, "Zhukeyi(Kaiyin,Datacom Standard&Patent)" <zhukeyi@huawei.com>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/a_NWLpMl9SUijL8lNHojCFkrGRI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Owner: <mailto:mpls-owner@ietf.org>
List-Post: <mailto:mpls@ietf.org>
List-Subscribe: <mailto:mpls-join@ietf.org>
List-Unsubscribe: <mailto:mpls-leave@ietf.org>

I think the new format only need a simple extension to existing mna hdr mechanism.
I can give a reference design for this type C’. It’s just like format C.
[cid:image001.png@01DAB7EB.14B7D340]
GL(group length) indicates the number of LSEs in this group.

If the data is short, I can only use this type C’, as A+B+C’.
It also support A+B+C’+D.
It’s completely  compatible with type C.

Tianran

From: Jaganbabu Rajamanickam (jrajaman) [mailto:jrajaman=40cisco.com@dmarc.ietf.org]
Sent: Wednesday, June 5, 2024 9:03 PM
To: Joel Halpern <jmh@joelhalpern.com>; Tianran Zhou <zhoutianran@huawei.com>; je_drake@yahoo.com
Cc: mpls@ietf.org; MPLS Working Chairs <mpls-chairs@ietf.org>; draft-ietf-mpls-mna-hdr@ietf.org; Zhukeyi(Kaiyin,Datacom Standard&Patent) <zhukeyi@huawei.com>
Subject: Re: [mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr

I agree with Tony and Joel,

IMO, the grouping may not be required, that could be achieved by the existing MNA hdr solution.

Option-1:
A Single opcode could define their own internal sub-actions as part of their AD and operate on it.
Example: Opcode=10 with AD length as 20 bits
                     The 20 bits AD could be split in to 4 bits sub-actions and 16 bits of AD
                     In this case, we could group four sub-actions and could enable and disable individually.

Option-2:
In the worst case a single opcodes could define multiple actions and include a single AD.
  Example: Opcode=10, Opcode=11
                       Could define a new opcode 12, that may execute the network action of 10 and 11 with the same AD


The grouping is going be more complex operations in the forwarding and the same behaviour could be achieved by the above.

Thanx,
Jags

From: Joel Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>
Date: Wednesday, June 5, 2024 at 8:39 AM
To: Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org<mailto:zhoutianran=40huawei.com@dmarc.ietf.org>>, je_drake@yahoo.com<mailto:je_drake@yahoo.com> <je_drake=40yahoo.com@dmarc.ietf.org<mailto:je_drake=40yahoo.com@dmarc.ietf.org>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org> <mpls@ietf.org<mailto:mpls@ietf.org>>, MPLS Working Chairs <mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>>, draft-ietf-mpls-mna-hdr@ietf.org<mailto:draft-ietf-mpls-mna-hdr@ietf.org> <draft-ietf-mpls-mna-hdr@ietf.org<mailto:draft-ietf-mpls-mna-hdr@ietf.org>>, Zhukeyi(Kaiyin,Datacom Standard&Patent) <zhukeyi@huawei.com<mailto:zhukeyi@huawei.com>>
Subject: Re: [mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr

I can not tell from the descriptions you have posted what change would be applied to the hdr draft.  Just saying "Some type C information can apply to following type C entries" seems so vague that I do not see how an implementor can use that information.  I can see how a specific solution could specify an opcode C1 and a furhter opcode C2 and could say C2 must follow C1 and uses the information from C1.  But that does not need any change to the hdr draft.

Yours,

Joel
On 6/5/2024 8:28 AM, Tianran Zhou wrote:
I do not really understand your question. Could you please give me more information?

Let me try to answer. Type c can have data. What l want to do is to reduce the redundant information when there are more than one actions.

Tianran


________________________________

Sent from WeLink
发件人: je_drake@yahoo.com<mailto:je_drake@yahoo.com><je_drake=40yahoo.com@dmarc.ietf.org<mailto:je_drake=40yahoo.com@dmarc.ietf.org>>
收件人: Tianran Zhou<zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>
抄送: John Drake<je_drake@yahoo.com<mailto:je_drake@yahoo.com>>;Tarek Saad<tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>>;mpls@ietf.org<mailto:mpls@ietf.org>;MPLS Working Chairs<mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>>;draft-ietf-mpls-mna-hdr@ietf.org<mailto:draft-ietf-mpls-mna-hdr@ietf.org>;Zhukeyi(Kaiyin,Datacom Standard&Patent)<zhukeyi@huawei.com<mailto:zhukeyi@huawei.com>>
主题: Re: [mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr
时间: 2024-06-05 00:30:48

You didn’t answer my question

Sent from my iPhone

On Jun 4, 2024, at 12:08 PM, Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org><mailto:zhoutianran=40huawei.com@dmarc.ietf.org> wrote:

Hi John,

One packet may need multiple actions/opcodes.
The group format will indicate several actions can share the same metadata.

Tianran
________________________________

Sent from WeLink
发件人: John Drake<je_drake=40yahoo.com@dmarc.ietf.org<mailto:je_drake=40yahoo.com@dmarc.ietf.org>>
收件人: Tarek Saad<tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>>;mpls@ietf.org<mailto:mpls@ietf.org>;Tianran Zhou<zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>
抄送: MPLS Working Chairs<mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>>;draft-ietf-mpls-mna-hdr@ietf.org<mailto:draft-ietf-mpls-mna-hdr@ietf.org>;Zhukeyi(Kaiyin,Datacom Standard&Patent)<zhukeyi@huawei.com<mailto:zhukeyi@huawei.com>>
主题: Re: [mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr
时间: 2024-06-04 21:36:51

So, for what are the post opcode bits in each of the subsequent format C LSEs used?

On Monday, June 3, 2024 at 08:40:12 PM PDT, Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org><mailto:zhoutianran=40huawei.com@dmarc.ietf.org> wrote:



Hi WG and Authors,



This draft proposed the 4 LSE formats with sequence: A-B-C-D.

I want to propose a new LSE format. Let’s call it C’ temporarily.

C’ is a kind of group, which can group several C formats.

So the sequence is A-B-C’-C-D.



This format can reduce the redundancy of several LSEs.

For example, if several LSEs have the same flow id, we can just put this flow id at the beginning of the group. And all the following LSEs in this group can use.



Best,

Tianran



From: Tarek Saad [mailto:tsaad.net@gmail.com]
Sent: Tuesday, June 4, 2024 10:50 AM
To: mpls@ietf.org<mailto:mpls@ietf.org>
Cc: MPLS Working Chairs <mpls-chairs@ietf.org><mailto:mpls-chairs@ietf.org>; draft-ietf-mpls-mna-hdr@ietf.org<mailto:draft-ietf-mpls-mna-hdr@ietf.org>
Subject: [mpls] Working Group Last Call on draft-ietf-mpls-mna-hdr



Dear WG,



This email starts a two-week Working Group last call for draft-ietf-mpls-mna-hdr<https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-hdr/>.



Please indicate your support or concern for this draft. If you are opposed to the progression of the draft to RFC, please articulate your concern. If you support it, please indicate that you have read the latest version, and it is ready for publication in your opinion. As always, review comments and nits are most welcome.



Please send your comments to the mpls WG mailing list (mpls@ietf.org<mailto:mpls@ietf.org>).

If necessary, comments may be sent unidirectional to the WG chairs.



Note, currently there are 5 IPR disclosures against this document at https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mpls-mna-hdr



This poll runs until June 18, 2024.



Thank you,

Tarek (for the MPLS WG co-chairs)
_______________________________________________
mpls mailing list -- mpls@ietf.org<mailto:mpls@ietf.org>
To unsubscribe send an email to mpls-leave@ietf.org<mailto:mpls-leave@ietf.org>
_______________________________________________
mpls mailing list -- mpls@ietf.org<mailto:mpls@ietf.org>
To unsubscribe send an email to mpls-leave@ietf.org<mailto:mpls-leave@ietf.org>


_______________________________________________

mpls mailing list -- mpls@ietf.org<mailto:mpls@ietf.org>

To unsubscribe send an email to mpls-leave@ietf.org<mailto:mpls-leave@ietf.org>