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

Aijun Wang <> Mon, 22 March 2021 03:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 574D53A10C0; Sun, 21 Mar 2021 20:57:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V6XHB5WwTVDh; Sun, 21 Mar 2021 20:57:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ADE1A3A10BE; Sun, 21 Mar 2021 20:57:19 -0700 (PDT)
Received: from DESKTOP2IOH5QC (unknown []) by (Hmail) with ESMTPA id 278741C0196; Mon, 22 Mar 2021 11:57:16 +0800 (CST)
From: "Aijun Wang" <>
To: <>, <>
Cc: <>
References: <>
In-Reply-To: <>
Date: Mon, 22 Mar 2021 11:57:15 +0800
Message-ID: <010f01d71ecf$72b9c600$582d5200$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQF5+g9UqT0wjWcvYUMbbc0LfQqsY6tJjTfw
Content-Language: zh-cn
X-HM-Tid: 0a7858146a6cd993kuws278741c0196
Archived-At: <>
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Mar 2021 03:57:27 -0000


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. 
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. 
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? 
4. For BT=0, the length is set to 7. How to skip the padding trailing zeros
to a 4-octet boundary when parsing?

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: <> On Behalf Of
Sent: Thursday, March 18, 2021 7:09 PM
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


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