Subject: [Pce] Moving PCE Allocation of Binding Label/SID to the BSID draft

From: Dhruv Dhody <[email-masked]>
Date: Wed, 20 Jan 2021 19:11:12 +0530

Hi WG, Authors,

As part of the handling of RTGDIR comments [1] for the PCECC I-D [2],
it was discovered that it is a better idea to handle the Binding SID
allocation by the PCE in the BSID I-D [3]. Julien and I agree.

Also, it makes sense to move the new P-flag in the LSP object here
(from path segment WG I-D [4]).

Cheng and I have this proposed update -

Diff: https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-binding-label-sid-05&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-06.txt

Please let us know if anyone has any concerns with this approach. This
draft is in our WG LC Queue [5].

Thanks!
Dhruv/Cheng

[1] https://mailarchive.ietf.org/arch/msg/rtg-dir/4n6FpBoDHjnGppKH4bcVotUu_hE/
[2] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/
[3] https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/
[4] https://datatracker.ietf.org/doc/draft-ietf-pce-sr-path-segment/
[5] https://trac.ietf.org/trac/pce/wiki/WikiStart#WGLastCallQueue

---

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 20 Jan 2021 16:48:46 +0000

Hi Dhruv,

I agree that pce sending down binding SID should be in the binding SID document, however I have some concerns regarding some of the text that requires PCECC capability exchange in order to allocate the value and erroring otherwise for a PCE-INIT. While the binding SID document is independent of SR Policy, one of its key usage is for SR Policy Candidate path. If a user wants to manually program an SR Policy CP and define a specific BSID and deploy it via PCEP PCE-INIT, I do not think there should be a requirement on PCECC capabilities to do so. While PCEP is not BGP of course, I can manually configure an SR Policy Candidate path with a BSID and inject with BGP without any pre-negotiations. This applies to Replication Segment as well. The BSID needs to be valid in SRLB, not necessarily a valid CCI related value?

Thanks!
Andrew

On 2021-01-20, 8:42 AM, "Pce on behalf of Dhruv Dhody" <[email-masked] on behalf of [email-masked]> wrote:

    Hi WG, Authors,

    Thanks!
    Dhruv/Cheng

    _______________________________________________
    Pce mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/pce

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 20 Jan 2021 23:56:09 +0530

Hi Andrew,

Thanks for your message.

The PCECC capability comes into play only when PCE also controls the
label space and it is the PCECC that is allocating the label
completely on its own.

The other case is for PCE to pick a specific value for BSID and ask
for the PCC to allocate and that does not require PCECC capability, it
remains distinct as noted in section 4.

   If a PCE requires a PCC to allocate a specific binding value, it may
   do so by sending a PCUpd or PCInitiate message containing a TE-PATH-
   BINDING TLV.  If the value can be successfully allocated, the PCC
   reports the binding value to the PCE.

I can tighten up the text in section 7 to make it clearer and avoid
any confusion.

Thanks!
Dhruv (as a WG participant)

---

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 20 Jan 2021 22:31:19 +0000

Ah I see that now. Okay cool, glad to hear.  

Thanks Dhruv!

Andrew

On 2021-01-20, 1:26 PM, "Dhruv Dhody" <[email-masked]> wrote:

    Hi Andrew,

    Thanks for your message.

    Thanks!

---

From: Siva Sivabalan <[email-masked]>
Date: Sun, 24 Jan 2021 19:13:20 -0500

Hi Dhruv and all:

*Section 7 states:*
Section 4 includes a case where a specified value for the binding
label/SID is requested to be allocated by the PCC.

*Section 4 (of v5) states:*

BINDING TLV.

Could we please add a bit more clarity to the motivation for the
proposed change ?

Also, we may want to indicate that how a PCE figures out the available
labels on a PCC, etc, is outside the scope of this ID.

Thanks,

Siva

On Wed, Jan 20, 2021 at 8:41 AM Dhruv Dhody <[email-masked]> wrote:

> Diff:
> https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-binding-label-sid-05&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-06.txt
>
> [1]
> https://mailarchive.ietf.org/arch/msg/rtg-dir/4n6FpBoDHjnGppKH4bcVotUu_hE/
> [2]
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/

---

From: "Mike Koldychev (mkoldych)" <[email-masked]>
Date: Mon, 25 Jan 2021 15:13:13 +0000

I’m also concerned about having PCECC as a requirement for anything in that draft. It would break backward compatibility.

Thanks,
Mike.

From: Pce <[email-masked]> On Behalf Of Siva Sivabalan
Sent: Sunday, January 24, 2021 7:13 PM
To: Dhruv Dhody <[email-masked]>
Cc: [email-masked]; [email-masked]; pce-chairs <[email-masked]>
Subject: Re: [Pce] Moving PCE Allocation of Binding Label/SID to the BSID draft

Hi Dhruv and all:

Section 7 states:
Section 4 includes a case where a specified value for the binding  label/SID is requested to be allocated by the PCC.

Section 4 (of v5) states:

If a PCE requires a PCC to allocate a specific binding value, it may do so by sending a PCUpd or PCInitiate message containing a TE-PATH-

BINDING TLV.

Could we please add a bit more clarity to the motivation for the proposed change ?

Also, we may want to indicate that how a PCE figures out the available labels on a PCC, etc, is outside the scope of this ID.

Thanks,

Siva

On Wed, Jan 20, 2021 at 8:41 AM Dhruv Dhody <[email-masked]<mailto:[email-masked]>> wrote:
Hi WG, Authors,

Thanks!
Dhruv/Cheng

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 25 Jan 2021 22:08:29 +0530

Hi Siva, Mike,

I have made an update to add more clarity in section 7.

Commit: https://github.com/dhruvdhody/ietf/commit/5c7e4625e8491fdece9007bec076a654bbeeaf93
Diff:  https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-binding-label-sid-05&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-06.txt

Just to clarify, this is not a new requirement, all that is being done
is moving the text from the PCECC I-D (which was already in post-WGLC)
to the BSID I-D. It is also marked that this feature is optional and
used only in the case the implementation also supports PCECC
operations and no change is made to any existing operations that could
lead to any backward compatibility issues.

Thanks!
Dhruv (as a WG member)

---

From: "Mike Koldychev (mkoldych)" <[email-masked]>
Date: Mon, 25 Jan 2021 16:58:17 +0000

Hi Dhruv,

My concern is about a PCC that DOES support PCE assigned BSID, but that DOES NOT support PCECC. Your latest diff still says that PCECC capability is needed for this PCC to be able to make use of PCE assigned BSID.

IMHO it should not be necessary to bring in support for PCECC, which is quite a large extension, just to allow a PCE to send down a BSID label to the PCC. PCE may have some other mechanism to figure out whether a BSID label is allocated or not.

Thanks,
Mike.

-----Original Message-----
From: Dhruv Dhody <[email-masked]> 
Sent: Monday, January 25, 2021 11:38 AM
To: Mike Koldychev (mkoldych) <[email-masked]>
Cc: Siva Sivabalan <[email-masked]>; [email-masked]; [email-masked]; pce-chairs <[email-masked]>
Subject: Re: [Pce] Moving PCE Allocation of Binding Label/SID to the BSID draft

Hi Siva, Mike,

Just to clarify, this is not a new requirement, all that is being done is moving the text from the PCECC I-D (which was already in post-WGLC) to the BSID I-D. It is also marked that this feature is optional and used only in the case the implementation also supports PCECC operations and no change is made to any existing operations that could lead to any backward compatibility issues.

Thanks!
Dhruv (as a WG member)

On Mon, Jan 25, 2021 at 8:43 PM Mike Koldychev (mkoldych) <[email-masked]> wrote:
> https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-
> binding-label-sid-05&url2=https://raw.githubusercontent.com/dhruvdhody
> /ietf/master/draft-ietf-pce-binding-label-sid-06.txt
>
> https://mailarchive.ietf.org/arch/msg/rtg-dir/4n6FpBoDHjnGppKH4bcVotUu
> _hE/ [2] 
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce
> -controller/ [3] 
> https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/

---

From: Siva Sivabalan <[email-masked]>
Date: Tue, 26 Jan 2021 09:57:51 -0500

Hi Dhruv,

I also agree with Mike. Let's not make BSID ID dependent on PCECC
capability.

Thanks,
Siva

On Mon, Jan 25, 2021 at 11:58 AM Mike Koldychev (mkoldych) <
[email-masked]> wrote:

> Hi Dhruv,
>
> My concern is about a PCC that DOES support PCE assigned BSID, but that
> DOES NOT support PCECC. Your latest diff still says that PCECC capability
> is needed for this PCC to be able to make use of PCE assigned BSID.
>
> IMHO it should not be necessary to bring in support for PCECC, which is
> quite a large extension, just to allow a PCE to send down a BSID label to
> the PCC. PCE may have some other mechanism to figure out whether a BSID
> label is allocated or not.
>
> Thanks,
> Mike.
>
> Cc: Siva Sivabalan <[email-masked]>; [email-masked];
> [email-masked]; pce-chairs <[email-masked]
> >
> Commit:
> https://github.com/dhruvdhody/ietf/commit/5c7e4625e8491fdece9007bec076a654bbeeaf93
> Diff:
> Just to clarify, this is not a new requirement, all that is being done is
> moving the text from the PCECC I-D (which was already in post-WGLC) to the
> BSID I-D. It is also marked that this feature is optional and used only in
> the case the implementation also supports PCECC operations and no change is
> made to any existing operations that could lead to any backward
> compatibility issues.
>
> Thanks!
> Dhruv (as a WG member)
>
>
> > I’m also concerned about having PCECC as a requirement for anything in
> that draft. It would break backward compatibility.
> >
> >
> >
> > Thanks,
> >
> > Mike.
> >
> >
> >

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 26 Jan 2021 21:54:03 +0530

Hi Siva,

I had a discussion with Mike, I explained that there are two different
cases here:

(1) PCE requests a specific binding value to be allocated by PCC (section 4)
(2) PCE controls the label space and allocates the label directly (new
section 7, text moved from PCECC I-D)

For (1) there is no dependency on PCECC capability!
Only for (2), which is a PCECC operation, the PCECC capability is checked.
The P flag helps to easily distinguish between the two cases.

Again, this is not a new feature, this was already part of a
post-WG-LC I-D, we are moving the text to BSID I-D here when the issue
was discovered during the RTGDIR review.

I added some more clarifications based on your and Mike's suggestions.
Here is the latest working copy -
https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-06.txt

If there is any text that is not clear or a change you would like to
see, please let me know.

Thanks!
Dhruv (as a WG member)

On Tue, Jan 26, 2021 at 8:28 PM Siva Sivabalan <[email-masked]> wrote:
>
> Hi Dhruv,
>
> I also agree with Mike. Let's not make BSID ID dependent on PCECC capability.
>
> Thanks,
> Siva
>
> On Mon, Jan 25, 2021 at 11:58 AM Mike Koldychev (mkoldych) <[email-masked]> wrote:
>>
>> Hi Dhruv,
>>

---

From: "Mike Koldychev (mkoldych)" <[email-masked]>
Date: Wed, 27 Jan 2021 17:49:01 +0000

Hi Dhruv,

It is more clear now, thanks. The P=1 basically means to allocate from PCE controlled space, while P=0 means to allocate from PCC controlled space.

I would just suggest to make the last sentence more specific to reflect this:

Current:
"PCE would directly allocate the label
   from the PCE-controlled label space using P=1 as described above,
   whereas PCE would request for the allocation of a specific BSID with
   P=0 as described in Section 4."

Proposed:
"PCE would allocate the label
   from the PCE-controlled label space using P=1 as described above,
   whereas PCE would request for the allocation from the PCC-controlled label space
   using P=0 as described in Section 4."

Thanks,
Mike.

-----Original Message-----
From: Dhruv Dhody <[email-masked]> 
Sent: Tuesday, January 26, 2021 11:24 AM
To: Siva Sivabalan <[email-masked]>
Cc: Mike Koldychev (mkoldych) <[email-masked]>; [email-masked]; [email-masked]; pce-chairs <[email-masked]>
Subject: Re: [Pce] Moving PCE Allocation of Binding Label/SID to the BSID draft

Hi Siva,

I had a discussion with Mike, I explained that there are two different cases here:

(1) PCE requests a specific binding value to be allocated by PCC (section 4)
(2) PCE controls the label space and allocates the label directly (new section 7, text moved from PCECC I-D)

Again, this is not a new feature, this was already part of a post-WG-LC I-D, we are moving the text to BSID I-D here when the issue was discovered during the RTGDIR review.

If there is any text that is not clear or a change you would like to see, please let me know.

Thanks!
Dhruv (as a WG member)

On Tue, Jan 26, 2021 at 8:28 PM Siva Sivabalan <[email-masked]> wrote:
>> [email-masked]; pce-chairs 
>> <[email-masked]>
>> https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce
>> -binding-label-sid-05&url2=https://raw.githubusercontent.com/dhruvdho
>> dy/ietf/master/draft-ietf-pce-binding-label-sid-06.txt
>>
>> > If a PCE requires a PCC to allocate a specific binding value, it 
>> > may do so by sending a PCUpd or PCInitiate message containing a 
>> > TE-PATH-
>> >
>> > BINDING TLV.
>> >
>> >
>> >
>> > As part of the handling of RTGDIR comments [1] for the PCECC I-D 
>> > [2], it was discovered that it is a better idea to handle the 
>> > Binding SID allocation by the PCE in the BSID I-D [3]. Julien and I agree.
>> >
>> > binding-label-sid-05&url2=https://raw.githubusercontent.com/dhruvdh
>> > ody /ietf/master/draft-ietf-pce-binding-label-sid-06.txt
>> >
>> > Please let us know if anyone has any concerns with this approach. 
>> > This draft is in our WG LC Queue [5].
>> >
>> > Thanks!
>> > Dhruv/Cheng
>> >
>> > [1]
>> > [4] 
>> > https://datatracker.ietf.org/doc/draft-ietf-pce-sr-path-segment/