Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

"Chengli (Cheng Li)" <c.l@huawei.com> Fri, 26 March 2021 07:01 UTC

Return-Path: <c.l@huawei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6603A135C; Fri, 26 Mar 2021 00:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JclW0qbhC-Yy; Fri, 26 Mar 2021 00:01:23 -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 1D2DD3A12E3; Fri, 26 Mar 2021 00:01:23 -0700 (PDT)
Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4F6CSD49fRz683Rh; Fri, 26 Mar 2021 14:56:28 +0800 (CST)
Received: from dggpemm100001.china.huawei.com (7.185.36.93) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 26 Mar 2021 08:01:15 +0100
Received: from dggpemm500003.china.huawei.com (7.185.36.56) by dggpemm100001.china.huawei.com (7.185.36.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 26 Mar 2021 15:01:13 +0800
Received: from dggpemm500003.china.huawei.com ([7.185.36.56]) by dggpemm500003.china.huawei.com ([7.185.36.56]) with mapi id 15.01.2106.013; Fri, 26 Mar 2021 15:01:13 +0800
From: "Chengli (Cheng Li)" <c.l@huawei.com>
To: "Chengli (Cheng Li)" <c.l@huawei.com>, Aijun Wang <wangaijun@tsinghua.org.cn>, "julien.meuric@orange.com" <julien.meuric@orange.com>, "pce@ietf.org" <pce@ietf.org>
CC: "draft-ietf-pce-binding-label-sid@ietf.org" <draft-ietf-pce-binding-label-sid@ietf.org>
Thread-Topic: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
Thread-Index: AQHXG+caJnUYRqZeiUCqBl16P0lEgaqO4PmAgAa2fUCAAEwVsA==
Date: Fri, 26 Mar 2021 07:01:13 +0000
Message-ID: <4b9d3c33b6ec41eab4f69acc4e17db2a@huawei.com>
References: <7010_1616065722_605334BA_7010_19_1_3f1d8d24-af98-f962-95ea-0e6ec46b738c@orange.com> <010f01d71ecf$72b9c600$582d5200$@tsinghua.org.cn> <0bf31f96c9e44597b8634e0f1efdac12@huawei.com>
In-Reply-To: <0bf31f96c9e44597b8634e0f1efdac12@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.130]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/HDu-9-KbsNo-Ia2VLfeiDetIUsA>
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Mar 2021 07:01:28 -0000

To all,

The latest diff of BSID draft is https://tools.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-pce-binding-label-sid-07.txt&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-08.txt

Sorry for using the wrong diff file.

Thanks,
Cheng



-----Original Message-----
From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Chengli (Cheng Li)
Sent: Friday, March 26, 2021 10:46 AM
To: Aijun Wang <wangaijun@tsinghua.org.cn>cn>; julien.meuric@orange.com; pce@ietf.org
Cc: draft-ietf-pce-binding-label-sid@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi Aijun,

Many thanks for your comments! Please see my reply inline. The diff is attached.

Respect,
Cheng



-----Original Message-----
From: Aijun Wang [mailto:wangaijun@tsinghua.org.cn] 
Sent: Monday, March 22, 2021 11:57 AM
To: julien.meuric@orange.com; pce@ietf.org
Cc: draft-ietf-pce-binding-label-sid@ietf.org
Subject: RE: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi, 

1. The concept of PCC requests the allocating of BSID for a LSP is clear, but the scenario that PCE allocate the BSID is not convincible. 
  PCE can request the PCC to allocate the BSID for one LSP. It should not allocate the value directly. 


[Cheng]Section 8 is optionally used when PCE is in control of label space (PCECC) and would not be used for vanilla stateful PCE.

2. What's the reason to include the BT=3, that is "SRv6 Endpoint Behavior and SID Structure"? It is one general information and not close connection to the normal usage of BSID. 
[Cheng] This is an alignment with other SIDs. In order to support backward compatibility, we want to remain BT2, and introduce a new BT for support SID structure. It can be used for future use case.


3. Will it be more clear to define one new bit(R bit) within the Flag field of "TE-PATH-BINDING TLV" to indicate clearly the remove of BSID allocation to a LSP? Instead of the implicit method that depending on the presence of TE-PATH-BINDING TLV as described in current draft? 
[Cheng] It is possible. But there are existing implementations that would get impacted.


4. For BT=0, the length is set to 7. How to skip the padding trailing zeros to a 4-octet boundary when parsing?
[Cheng] We have updated the description of BT=0 as per Adrian's comment. Length=7 and handling of padding is as per RFC5440: 

   The Length field defines the length of the value portion in bytes.
   The TLV is padded to 4-bytes alignment; padding is not included in
   the Length field (so a 3-byte value would have a length of 3, but the
   total size of the TLV would be 8 bytes).

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: pce-bounces@ietf.org <pce-bounces@ietf.org> On Behalf Of julien.meuric@orange.com
Sent: Thursday, March 18, 2021 7:09 PM
To: pce@ietf.org
Cc: draft-ietf-pce-binding-label-sid@ietf.org
Subject: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi all,

This message initiates a 2-week PCE WG Last Call for draft-ietf-pce-binding-label-sid-07. Please review and share your feedback, whatever it is, using the PCE mailing list. This WGLC will end on Thursday April 1st (no kidding).


Moreover, we have received a request from the authors for a code point allocation to support interoperability testing.

RFC 7120 requires to meet the following criteria to proceed:

b. The format, semantics, processing, and other rules related to handling the protocol entities defined by the code points (henceforth called
"specifications") must be adequately described in an Internet-Draft.
c. The specifications of these code points must be stable; i.e., if there is a change, implementations based on the earlier and later specifications must be seamlessly interoperable.

If anyone believes that the draft does not meet these criteria, or believes that early allocation is not appropriate for any other reason, please send an email to the PCE mailing list explaining why. If the chairs hear no objections by Thursday, March 25th, we will kick off the "early" allocation request.

Thanks,

Dhruv & Julien


____________________________________________________________________________
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce