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

olivier.dugeon@orange.com Fri, 02 April 2021 18:00 UTC

Return-Path: <olivier.dugeon@orange.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 9D6C33A1F1E; Fri, 2 Apr 2021 11:00:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.192
X-Spam-Level:
X-Spam-Status: No, score=0.192 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FORGED_MUA_MOZILLA=2.309, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 nmIElN_e1sWR; Fri, 2 Apr 2021 11:00:23 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72BC3A1F14; Fri, 2 Apr 2021 11:00:22 -0700 (PDT)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 4FBns00DD1z7tmW; Fri, 2 Apr 2021 20:00:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1617386420; bh=geuhUcffUgY7LDOLp7Eyy9E6PBhYFy3xstFjMtbYS98=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type; b=dP78qUPQyh3e/uytiTI5Ofx9I70lg2aZ68YC6llhKGISkrFPJ9AWUpoyVASkPrAk8 L0vvCnn/NkGlx5QsYOrA5yCN1J41goU2ass1USJnHR0ZIW4Xit28tx/qQTyWcyK1HJ SZlQnerrpjnPIJt+vPLZ+kf3SCnMrGaL0o3zkTtbnzl7jGI2lr8CmQptGdCWIaMHhW cmrWbBrWCrpmWj5IIujgyGFUNt1sUHhya3i2EbKu0WbteI3AEz2r2qNM6s0yjxtWtp OJNz53hAcdjU9/5OuzlZeXHpC2kusbNL4W+Wb9oHP5sHe0QUdjouYFOwYwNugy+aYk g3EVIKJtE0yhQ==
Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.63]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4FBnrz66Jlz3wbB; Fri, 2 Apr 2021 20:00:19 +0200 (CEST)
Received: from [10.192.148.172] (10.114.50.248) by exchange-eme3.itn.ftgroup (10.114.50.63) with Microsoft SMTP Server (TLS) id 14.3.498.0; Fri, 2 Apr 2021 20:00:19 +0200
To: Dhruv Dhody <dd@dhruvdhody.com>
CC: "draft-ietf-pce-binding-label-sid@ietf.org" <draft-ietf-pce-binding-label-sid@ietf.org>, "pce@ietf.org" <pce@ietf.org>
References: <7010_1616065722_605334BA_7010_19_1_3f1d8d24-af98-f962-95ea-0e6ec46b738c@orange.com> <010f01d71ecf$72b9c600$582d5200$@tsinghua.org.cn> <0bf31f96c9e44597b8634e0f1efdac12@huawei.com> <12637_1617213626_6064B8BA_12637_79_1_0ab201c2-238c-4df6-b271-4b6d105381ec@OPEXCNORM64.corporate.adroot.infra.ftgroup> <CAP7zK5Zay4KUoPY679rOZWXFyRxRJFBEgJuJfEUMfebDNvk7Zg@mail.gmail.com> <27177_1617272382_60659E3E_27177_170_1_16b05df1-309e-41e5-a199-85d213aef493@OPEXCNORM3D.corporate.adroot.infra.ftgroup> <9278_1617357136_6066E950_9278_411_1_cca8d003-937b-6035-549b-c77dbf0e5fbf@orange.com> <CAP7zK5bNhHRch6iyapQ80GEnW-1TGzeKcDQcgc4EwYyH=L4jnQ@mail.gmail.com>
From: <olivier.dugeon@orange.com>
Organization: Orange Labs
Message-ID: <8281_1617386419_60675BB3_8281_56_1_3e1134f3-70dd-0417-a2b5-37334b8e6503@orange.com>
Date: Fri, 2 Apr 2021 20:00:17 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAP7zK5bNhHRch6iyapQ80GEnW-1TGzeKcDQcgc4EwYyH=L4jnQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------86D209C35AE2CD468C667EAC"
Content-Language: en-GB
X-Originating-IP: [10.114.50.248]
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/HUVDaJA3zE3YPeNl61XyGCxw0eU>
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, 02 Apr 2021 18:00:28 -0000

Hi Dhruv,

Speaking as an OpenDaylight developer and committer of BGPCEP project (for controller part), as well as FreeRange Routing developer and maintainer (for router part):

Le 02/04/2021 à 16:59, Dhruv Dhody a écrit :
> Hi Olivier,
[ ... ]
>  
>
>     In fact, if I correctly understand, the proposed mechanism impose to synchronise
>     permanently the whole list of BSID instead of managing individual BSID,
>     which, IMHO, is preferable.
>
>
> That is correct. PCEP speakers include all the TE-PATH-BINDING TLVs.
>
> The author's preference for the current text seems to be to avoid impacting existing implementations. It would be good to hear from implementors on this! 

If it is feasible, synchronizing two lists is much more complicated and much more time CPU consumption compared to manage one BSID at once.

In fact, it depends if the list remains ordered or not. e.g. if the TE-PATH-BINDING list is always BSID1, BSID2, BSID3 ... it is possible to find a simple algorithm. But, if one time it is BSID1, BSID2, BSID3, ... and the next time BSID2, BSID3, BSID1 ... there is a large risk to modify the wrong Binding SID if you chose the wrong algorithm. Thus, this behaviour will not simplify the life of developers.

Regards

Olivier

> Thanks!
> Dhruv
>  
>
>
>
>  
>
>     Regards
>
>     Olivier
>
>     Le 01/04/2021 à 12:19, olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com> a écrit :
>>     Hi Dhruv,
>>
>>     New text is better, but the solution remains perfectible and not safer.
>>     Again, it makes the assumption that PCE and PCC are perfectly synchronised regarding
>>     the TE-PATH-BINDING table which could not be the case. This mechanism is only working
>>     well if implementation has been correctly written. In case of error, bug, whatever you could
>>
>>     imagine, removal of TE-PATH-BINDING could not work as expected.
>>     From a protocol pointof view, it is not safer. In PCEP, there is a 'R' flag when you would
>>     remove an LSP with thePcUpdate/PcInitiate message. For me, it is the same behaviour.
>>     You explicitly remove an LSPby providing the LSP information + the 'R' flag set.
>>     I don't understand why it is not the samefor all PCEP TLVs.
>>
>>     Regards
>>
>>     Olivier
>>
>>     Le 31/03/2021 à 20:38, Dhruv Dhody a écrit :
>>>     Hi Olivier, 
>>>
>>>     On Wed, Mar 31, 2021 at 11:30 PM <olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>> wrote:
>>>
>>>         Hi Cheng, Aijun,
>>>
>>>         I think that the 'R' bit to clearly indicate that BSID is removed
>>>         is mandatory. In fact, in case of multiple BSID, it will become clearly
>>>         a nightmare from an implementation point of view to manage the removal.
>>>
>>>         Let me take a simple example:
>>>
>>>         Assume a PCE would setup some BSID into a PCC. It first send a PcInitiate
>>>         message with an empty TE-PATH-BINDING TLV to request a BSID. PCC send a PcRpt
>>>         message with a BSID=1 (simple value). Then, the PCE would a second BSID. So, it
>>>         sends a PcUpdate message with a TE-PATH-BINDING TLV and the first BSID=1 and a
>>>         second empty TE-PATH-BINDING TLV to get the second one. PCC sends back a PcRpt
>>>         message with the 2 TE-PATH-BINDING BSID=1 and BSDI=2. We repeat the last operation
>>>         to collect a third BSID=3. Now the PCE would remove the BSID=2. It must send a
>>>         PcUpdate message with TE-PATH-BINDING BSID=1, TE-PATH-BINDING BSID=3 and an
>>>         empty TE-PATH-BINDING.
>>>
>>>         So, how the PCC could determine that this last emptyTE-PATH-BINDING corresponds
>>>         to a deletion and not a creation ?
>>>
>>>
>>>     Looking at the working copy[1]/diff[2] that Cheng posted, the empty TE-PATH-BINDING TLV is used to request allocation only (and not to withdraw old values). So in the example above to remove BSID=2, the PCUpd message with TE-PATH-BINDING BSID=1 & TE-PATH-BINDING BSID=3 are sent.
>>>
>>>     Adrian provided some cleaner text that has been incorporated for this now. Does the updated text resolve this?
>>>
>>>     Thanks!
>>>     Dhruv (as a WG participant)
>>>
>>>     [1] https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-08.txt
>>>     [2] 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
>>>      
>>>
>>>         There is a large risk of ambiguity in particular if the PCE does not send
>>>         the TE-PATH-BINDING TLVs in the right order, if PCE and PCC become de-synchronize
>>>         on the number of BSID ...
>>>
>>>         Thus, I think that a 'R' bit for deletion is mandatory.
>>>
>>>         Regards
>>>
>>>         Olivier
>>>
>>>         Le 26/03/2021 à 03:46, Chengli (Cheng Li) a écrit :
>>>         > 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 <mailto:wangaijun@tsinghua.org.cn>]
>>>         > Sent: Monday, March 22, 2021 11:57 AM
>>>         > To: julien.meuric@orange.com <mailto:julien.meuric@orange.com>; pce@ietf.org <mailto:pce@ietf.org>
>>>         > Cc: draft-ietf-pce-binding-label-sid@ietf.org <mailto: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 <mailto:pce-bounces@ietf.org> <pce-bounces@ietf.org <mailto:pce-bounces@ietf.org>> On Behalf Of julien.meuric@orange.com <mailto:julien.meuric@orange.com>
>>>         > Sent: Thursday, March 18, 2021 7:09 PM
>>>         > To: pce@ietf.org <mailto:pce@ietf.org>
>>>         > Cc: draft-ietf-pce-binding-label-sid@ietf.org <mailto: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 <mailto:Pce@ietf.org>
>>>         > https://www.ietf.org/mailman/listinfo/pce
>>>         >
>>>         >
>>>         > _______________________________________________
>>>         > Pce mailing list
>>>         > Pce@ietf.org <mailto:Pce@ietf.org>
>>>         > https://www.ietf.org/mailman/listinfo/pce
>>>         -- 
>>>         Orange logo <http://www.orange.com>
>>>
>>>          
>>>
>>>         Olivier Dugeon
>>>         Orange Expert, Future Networks
>>>         Open Source Referent
>>>         Orange/IMT/OLN/WTC/IEE/iTeQ
>>>
>>>          
>>>
>>>         fixe : +33 2 96 07 28 80
>>>         mobile : +33 6 82 90 37 85
>>>         olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com> <mailto:olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>>
>>>
>>>
>>>         _________________________________________________________________________________________________________________________
>>>
>>>         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 <mailto:Pce@ietf.org>
>>>         https://www.ietf.org/mailman/listinfo/pce
>>>
>>     -- 
>>     Orange logo <http://www.orange.com>
>>
>>      
>>
>>     Olivier Dugeon
>>     Orange Expert, Future Networks
>>     Open Source Referent
>>     Orange/IMT/OLN/WTC/IEE/iTeQ
>>
>>      
>>
>>     fixe : +33 2 96 07 28 80
>>     mobile : +33 6 82 90 37 85
>>     olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>
>>     _________________________________________________________________________________________________________________________
>>
>>     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 <mailto:Pce@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/pce
>     -- 
>     Orange logo <http://www.orange.com>
>
>      
>
>     Olivier Dugeon
>     Orange Expert, Future Networks
>     Open Source Referent
>     Orange/IMT/OLN/WTC/IEE/iTeQ
>
>      
>
>     fixe : +33 2 96 07 28 80
>     mobile : +33 6 82 90 37 85
>     olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>
>
>     _________________________________________________________________________________________________________________________
>
>     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.
>
-- 
Orange logo <http://www.orange.com>

 

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/iTeQ

 

fixe : +33 2 96 07 28 80
mobile : +33 6 82 90 37 85
olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>

_________________________________________________________________________________________________________________________

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.