Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

"Wanghaibo (Rainsword)" <rainsword.wang@huawei.com> Thu, 03 December 2020 10:09 UTC

Return-Path: <rainsword.wang@huawei.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2850C3A0E1E; Thu, 3 Dec 2020 02:09:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoscOJh9juA0; Thu, 3 Dec 2020 02:09:35 -0800 (PST)
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 5FB383A0E19; Thu, 3 Dec 2020 02:09:35 -0800 (PST)
Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Cms2K3D7hz67F1B; Thu, 3 Dec 2020 18:07:05 +0800 (CST)
Received: from nkgeml709-chm.china.huawei.com (10.98.57.40) 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.2106.2; Thu, 3 Dec 2020 11:09:27 +0100
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml709-chm.china.huawei.com (10.98.57.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 3 Dec 2020 18:09:26 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Thu, 3 Dec 2020 18:09:26 +0800
From: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>, "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>, "draft-ietf-bess-srv6-services@ietf.org" <draft-ietf-bess-srv6-services@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05
Thread-Index: AQHWxzqkfE02MgFzNEuKoML7MFiv86nkpG9AgABwkgCAABIV4A==
Date: Thu, 03 Dec 2020 10:09:25 +0000
Message-ID: <20647c3faf9b4cb2ab5ba7d24d2ba376@huawei.com>
References: <VI1PR0701MB69918DAD0FDF3C7E18BB53E9EBF50@VI1PR0701MB6991.eurprd07.prod.outlook.com> <957470ffb1b54c65838ff8a5f7a52869@huawei.com> <MW3PR11MB457069173329FBB9EDF4F7A4C1F20@MW3PR11MB4570.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB457069173329FBB9EDF4F7A4C1F20@MW3PR11MB4570.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.108.201.194]
Content-Type: multipart/related; boundary="_004_20647c3faf9b4cb2ab5ba7d24d2ba376huaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/2lHsWHI18ePgO8PQOE4K66iVh1w>
Subject: Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2020 10:09:38 -0000

Hi Ketan,

         Thanks for your reply.

RFC 8277 has clearly described that the label field is only 20 bits.

At the beginning, we consider it to use the 20-bits to do the transposition. But in some interconnection tests, some vendors are use the 24-bits to do the transposition.

So I’m worried about that the change may cause incompatible interop.

Regards,
Haibo

From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
Sent: Thursday, December 3, 2020 5:01 PM
To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com>; Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com>; draft-ietf-bess-srv6-services@ietf.org; bess@ietf.org
Subject: RE: WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

Hi Haibo,

This clarification was explicitly added based on feedback that the authors received.

This document does not change the definition of the Label Field of RFC4364 and so it has always been 20 bits. There has been this text about 24-bit in other parts of the draft since RFC7432 allows that.

If you see the previous versions of this document, the encoding of the label was also previously clarified with a reference to RFC8277.

Regarding the BOS bit, the clarification is provided by RFC8277. Previously, this was under-specified by RFC3107. There are implementations around that do not check/examine the BOS field and assume a single label. You can see some of this history captured in RFC8277.

Thanks,
Ketan

From: Wanghaibo (Rainsword) <rainsword.wang@huawei.com<mailto:rainsword.wang@huawei.com>>
Sent: 03 December 2020 09:13
To: Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com<mailto:matthew.bocci@nokia.com>>; draft-ietf-bess-srv6-services@ietf.org<mailto:draft-ietf-bess-srv6-services@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05


Dear authors and all,



 I find the following changes in the new version, which may cause incompatible changes in the implemented version.
[cid:image001.png@01D6C99E.5738BC00]


The label field described in RFC4364:

4.3.4. How VPN-IPv4 NLRI Is Carried in BGP

   The labeled VPN-IPv4 NLRI itself is encoded as specified in

   [MPLS-BGP<https://tools.ietf.org/html/rfc4364#ref-MPLS-BGP>], where the prefix consists of an 8-byte RD followed by an

   IPv4 prefix.


 RFC 3107 describe the label field:

3. Carrying Label Mapping Information

      b) Label:



         The Label field carries one or more labels (that corresponds to

         the stack of labels [MPLS-ENCAPS<https://tools.ietf.org/html/rfc3107#ref-MPLS-ENCAPS>]).  Each label is encoded as 3

         octets, where the high-order 20 bits contain the label value,

         and the low order bit contains "Bottom of Stack" (as defined in

         [MPLS-ENCAPS<https://tools.ietf.org/html/rfc3107#ref-MPLS-ENCAPS>]).


According to the definition, the label field in RFC 4364 should be 3 bytes,  but only 20 bits are used as the label value. So we may also use the entire 3 octets.

On the other hand,  if only 20 bits are used, do we need to add the BoS flag to the part when do the transposition?



Best Regards,

Haibo

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Tuesday, December 1, 2020 1:16 AM
To: draft-ietf-bess-srv6-services@ietf.org<mailto:draft-ietf-bess-srv6-services@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

This email starts a two-week working group last call for draft-ietf-bess-srv6-services-05 [1]

Please review the draft and send any comments to the BESS list. Also, please indicate if you support publishing the draft as a standards track RFC.

This poll runs until Monday 14th December 2020.

We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this document please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress without answers from all the Authors and Contributors.
There is currently one IPR disclosure.

In addition, we are polling for knowledge of implementations of this draft, per the BESS policy in [2].

Thank you,
Matthew & Stephane


[1] https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw