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

[olivier.dugeon]

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. 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 
> presen

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

[tom petch]

From: julien.meu...@orange.com 
Sent: 30 March 2021 11:47
To: tom petch
Cc: pce@ietf.org; adr...@olddog.co.uk; 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 Tom,

What really matters for the IANA early allocation is that the behaviors
associated to the code points are clear and stable. Assuming the WG
agrees on moving to the "binding value" terminology all along the
document, then the technical specification wouldn't change (i.e. it
would clearly be backward compatible [1]) and we could update the phrase
in IANA entry accordingly at final allocation time.


I understand what you are saying but I also believe in
Get it Right First Time
that is getting it wrong and then changing it leads to a greater cost, to 
confusion and to mistakes.  I see this  with YANG modules where some way 
through the development, someone has a good idea and changes the YANG prefix, 
except that they change it in some places and not in others.  There have been 
cases where this has been detected and fixed at the RFC Editor stage, there are 
others where it has not and a published RFC has two different values which 
contradicts the BCP on YANG Guidelines.

So good ideas, on such as an identifier, need to happen early one, before 
adoption of an I-D IMHO which is why you may find me opposing adoption of an 
individual submission because I see the consequences in the long term of a less 
than ideal choice of identifier.

Tom Petch.

Cheers,

Julien

--
[1] https://www.rfc-editor.org/rfc/rfc7120.html#section-3.2


On 27/03/2021 13:02, tom petch wrote:
> 
> Adrian
>
> I share your comments about the terminology in this I-D which is not precise, 
> failing to specify 'MPLS label' and failing to use 'MPLS label stack entry' 
> but I think that the worst part is this 'binding/Label SID' which to me is a 
> classic example of how not to choose an identifier.  The I-D does use 
> 'binding value' in one place as what appears to be one of the many different 
> terms for this concept and I think that term much better.
>
> Since this term, whatever it is, gets embedded in IANA, I said that the IANA 
> early allocation should not proceed until this is resolved, but you may not 
> take it that far.
>
> Tom Petch


_

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

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

[Gyan Mishra]

Thank you Bin for your sharing your positive experience with PCEP-LS in the
field and continued experimenting in scenarios such as H-PCE and PCECC.

Thank you for supporting this experimental draft and interest in
progressing.


Kind Regards

Gyan


On Thu, Apr 1, 2021 at 1:00 AM 윤빈영  wrote:

> Hi Gyan,
>
>
> We have implemented PCEP in the past.
>
> This experimental upgrade of PCEP to enable direct TE updates to PCE is
> worth to try and we'd be interested in the implementation of this work.
>
>
> Regards,
>
> Bin
>
>
> *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*
>
> --



*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

[Naas Transformation 팀]

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 mailto:hayabusa...@gmail.com>>
Sent: Thursday, March 18, 2021 11:36 AM
To: pce@ietf.org; 
draft-dhodylee-pce-pcep...@ietf.org;
 Dhruv Dhody mailto:d...@dhruvdhody.com>>; Adrian Farrel 
mailto:adr...@olddog.co.uk>>
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/

==



[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]

Gyan Mishra

Network Solutions Architect

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

M 301 502-1347

[https://gov-dooray.com/mail-receipts?img=505164536d774c31-255f27ea7e6d48ae-295471e8682825ad-295472e655bcd410.gif]




이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에 포함된 
정보의 전부 또는 일부를 무단으로 제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.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Aijun Wang]

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 mailto:hayabusa...@gmail.com> > 
Sent: Thursday, March 18, 2021 11:36 AM
To: pce@ietf.org  ; draft-dhodylee-pce-pcep...@ietf.org 
 ; Dhruv Dhody mailto:d...@dhruvdhody.com> >; Adrian Farrel mailto:adr...@olddog.co.uk> >
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.

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