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

[olivier.dugeon]

Hi Dhruv,

After re-thinking about the new text, I discovered another potential mistake:

Example, you have 3 BSID: BSID1, BSID2, BSID3.

To remove BSID2, PCE should send a PcUpd message with only BSID1 and BSID3
Once remove, if PCE would modify BSID3, it should send a PcUpd message with 
BSID1 and new BSID3

So, how do you make the distinction, from a protocol and parsing point of view, 
between
a PcUpdate message that is used to i) remove a BSID from ii) update a BSID ?

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.

Regards

Olivier

Le 01/04/2021 à 12:19, olivier.dug...@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 > > 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:wangai...@tsinghua.org.cn 
>> ]
>> > Sent: Monday, March 22, 2021 11:57 AM
>> > To: julien.meu...@orange.com ; 
>> pce@ietf.org 
>> > Cc: draft-ietf-pce-binding-label-...@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. 

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

[Dhruv Dhody]

Hi Olivier,

As a WG member...
On Fri, Apr 2, 2021 at 3:22 PM  wrote:

> Hi Dhruv,
>
> After re-thinking about the new text, I discovered another potential
> mistake:
>
> Example, you have 3 BSID: BSID1, BSID2, BSID3.
>
> To remove BSID2, PCE should send a PcUpd message with only BSID1 and BSID3
> Once remove, if PCE would modify BSID3, it should send a PcUpd message
> with BSID1 and new BSID3
>
> So, how do you make the distinction, from a protocol and parsing point of
> view, between
> a PcUpdate message that is used to i) remove a BSID from ii) update a BSID
> ?
>
>
The key is for PCE to send all TE-PATH-BINDING TLVs that it wishes to apply
from that point on.

PCC compares them to the existing binding values to find -
- the binding values that are the same (no change, nothing needs to be done)
- the binding values that are missing from PCE (that needs to be deleted)
- the binding values that are new (that needs to be allocated)

There is no need to differentiate between (i) and (ii) in your example, the
processing at the PCC would be the same anyways.



> 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!
Thanks!
Dhruv






> Regards
>
> Olivier
>
> Le 01/04/2021 à 12:19, olivier.dug...@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 point of view, it is not safer. In PCEP, there is a 'R'
> flag when you would
> remove an LSP with the PcUpdate/PcInitiate message. For me, it is the
> same behaviour.
> You explicitly remove an LSP by providing the LSP information + the 'R'
> flag set.
> I don't understand why it is not the same for 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  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:wangai...@tsinghua.org.cn]
>> > Sent: Monday, Marc

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

[olivier.dugeon]

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.dug...@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 >> > 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, Che

Re: [Pce] draft-dhodylee-pce-pcep-te-data-extn

[Gyan Mishra]

Hi Aijun

That’s great to here interest from operators in PCEP-LS!

Kind Regards

Gyan
On Thu, Apr 1, 2021 at 9:30 PM Aijun Wang  wrote:

> Hi,
>
>
>
> Also as a telco, we are expecting the implementation of PCEP-LS, and once
> it is ready, we will try to deploy it in the network.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* pce-boun...@ietf.org  *On Behalf Of *???(Naas
> Transformation ?)
> *Sent:* Friday, April 2, 2021 9:14 AM
> *To:* Gyan Mishra ; pce@ietf.org;
> draft-dhodylee-pce-pcep...@ietf.org; Dhruv Dhody ;
> Adrian Farrel 
> *Subject:* Re: [Pce] draft-dhodylee-pce-pcep-te-data-extn
>
>
>
> Dear Gyan,
>
>
>
> As a telco, we are interested in the upgrade of PCEP.
>
> PCEP and H-PCE scenarios is always being considered as valuable tools for
> solving our issues in telco’s multi-domain environment.
>
>
>
> Regards,
>
> Peter
>
>
>
>
>
> *From:* Gyan Mishra 
> *Sent:* Thursday, March 18, 2021 11:36 AM
> *To:* pce@ietf.org; draft-dhodylee-pce-pcep...@ietf.org; Dhruv Dhody <
> d...@dhruvdhody.com>; Adrian Farrel 
> *Subject:* [Pce] draft-dhodylee-pce-pcep-te-data-extn
>
>
>
> Dear PCE WG,
>
>
>
> We presented the PCEP-LS [1] I-D [2] in the IETF 110 with a quick recap
> and a summary of past discussions. Some new scenarios such as PCECC, H-PCE
> were highlighted where the PCEP session could be reused.
>
>
>
> This is an experimental I-D with the aim to progress research and
> development efforts. This work is not a replacement for any of the existing
> mechanisms. There are specific scenarios highlighted where the reuse of
> PCEP sessions for this information is deemed useful. To make progress, it
> may not be useful to rehash the beauty context between everyone's favorite
> protocol :). What would be useful would be - finding out if there is still
> interest in this experimental work by some in the WG; are there strong
> technical objections for the experiment in its limited scope etc...
>
>
>
> As a next step, it would be good to define the scope of the experiments
> and expected output especially targeting the scalability concerns as well
> as impact in other protocols and the network, etc.
>
>
>
> Thanks!
>
> Gyan (on behalf of co-authors)
>
>
>
> [1]
> https://datatracker.ietf.org/meeting/110/materials/slides-110-pce-42-pcep-ls-00.pdf
>
> [2] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/
>
> ==
>
>
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mis...@verizon.com *
>
> *M 301 502-1347*
>
>
>
>
>
>
>
> 이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에
> 포함된 정보의 전부 또는 일부를 무단으로 제3자에게 공개, 배포, 복사 또는 사용하는 것을 엄격히 금지합니다. 만약, 본 메일이 잘못
> 전송된 경우, 발신인 또는 당사에 알려주시고, 본 메일을 즉시 삭제하여 주시기 바랍니다.
> This E-mail may contain confidential information and/or copyright
> material. This email is intended for the use of the addressee only. If you
> receive this email by mistake, please either delete it without reproducing,
> distributing or retaining copies thereof or notify the sender immediately.
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] draft-dhodylee-pce-pcep-te-data-extn

[Gyan Mishra]

Hi Peter

That’s good to hear interest from operators such as yourself in PCEP-LS.
As you deploy PCECC and H-PCE in a multi domain environments you will be
able to reuse the SBI PCEP session for PCEP-LS and then can take full
advantage of some of benefits of PCEP-LS such as synchronization
optimization and incremental updates.

Thank you for sharing your interest in PCEP-LS.

Kind Regards

Gyan

On Thu, Apr 1, 2021 at 9:14 PM 박춘걸(Naas Transformation 팀) 
wrote:

> Dear Gyan,
>
>
>
> As a telco, we are interested in the upgrade of PCEP.
>
> PCEP and H-PCE scenarios is always being considered as valuable tools for
> solving our issues in telco’s multi-domain environment.
>
>
>
> Regards,
>
> Peter
>
>
>
>
>
> *From:* Gyan Mishra 
> *Sent:* Thursday, March 18, 2021 11:36 AM
> *To:* pce@ietf.org; draft-dhodylee-pce-pcep...@ietf.org; Dhruv Dhody <
> d...@dhruvdhody.com>; Adrian Farrel 
> *Subject:* [Pce] draft-dhodylee-pce-pcep-te-data-extn
>
>
>
> Dear PCE WG,
>
>
>
> We presented the PCEP-LS [1] I-D [2] in the IETF 110 with a quick recap
> and a summary of past discussions. Some new scenarios such as PCECC, H-PCE
> were highlighted where the PCEP session could be reused.
>
>
>
> This is an experimental I-D with the aim to progress research and
> development efforts. This work is not a replacement for any of the existing
> mechanisms. There are specific scenarios highlighted where the reuse of
> PCEP sessions for this information is deemed useful. To make progress, it
> may not be useful to rehash the beauty context between everyone's favorite
> protocol :). What would be useful would be - finding out if there is still
> interest in this experimental work by some in the WG; are there strong
> technical objections for the experiment in its limited scope etc...
>
>
>
> As a next step, it would be good to define the scope of the experiments
> and expected output especially targeting the scalability concerns as well
> as impact in other protocols and the network, etc.
>
>
>
> Thanks!
>
> Gyan (on behalf of co-authors)
>
>
>
> [1]
> https://datatracker.ietf.org/meeting/110/materials/slides-110-pce-42-pcep-ls-00.pdf
>
> [2] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/
>
> ==
>
>
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mis...@verizon.com *
>
> *M 301 502-1347*
>
>
>
>
>
>
> 이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에
> 포함된 정보의 전부 또는 일부를 무단으로 제3자에게 공개, 배포, 복사 또는 사용하는 것을 엄격히 금지합니다. 만약, 본 메일이 잘못
> 전송된 경우, 발신인 또는 당사에 알려주시고, 본 메일을 즉시 삭제하여 주시기 바랍니다.
> This E-mail may contain confidential information and/or copyright
> material. This email is intended for the use of the addressee only. If you
> receive this email by mistake, please either delete it without reproducing,
> distributing or retaining copies thereof or notify the sender immediately.
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce