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

From: <[email-masked]>
Date: Thu, 18 Mar 2021 12:08:40 +0100

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.

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 19 Mar 2021 02:20:21 +0000

Many thanks Dhruv and Julien!

I support the adoption and early allocation as a co-author. Luckily,  before April 1st.

Thank you for your work!

Respect!
Cheng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 18, 2021 7:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: 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.

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.

---

From: <[email-masked]>
Date: Fri, 19 Mar 2021 17:39:15 +0100

Hi all,

I support adoption of this draft, but I have a certain number of
questions for the authors:

 - As far as I know, routers manage their MPLS label allocation by interface,
   except for Segment Routing which uses an SRGB. In the draft, you mention
   that the BSID, associated with a given LSP, could be taken from the SRGB or
   from a local block. Does this imply that the BSID value must be available for
   all interfaces? (i.e. all packets arriving on any interface with the BSID will
   be forwarded in the LSP) or does the BSID only depend on the source IP address
   of the LSP? But, in the latter case, if this source IP address corresponds to
   a loopback interface (the most frequent case), the BSID becomes de facto
   global. So, if the BSID does not have a global meaning, should the
   TE-Path-Binding TLV contain a reference (e.g. the IP address) to the interface
   to which this BSID is associated?

 - In the draft, you mention that there could be several TE-PATH-BINDING TLVs in
   the LSP object (I assume one TE-Path-Binding per BSID). In case a PCE requests
   multiple BSIDs from a PCC via a PCupd or PCInitiate message for a given LSP,
   should the PCE insert as many empty TE-PATH-BINDING TLVs as requested BSIDs?
   Similarly, if the PCE wishes to add an additional BSID, should it insert the
   TE-PATH-BINDING TLVs corresponding to the previously allocated BSIDs plus an
   empty TE-PATH-BINDING TLV for the new BSID?

 - Once the BSID is allocated, is it advertised (flooded) in the IGP for use by
   other routers in the network or does it remain under the control of the PCE?
   As there may be use cases for both scenarios, should a new flag be added to
   indicate whether the BSID is to be advertised or not in the IGP?

 - In the case of hierarchical paths, how could we use BSID? For example: we would
   route 2 LSPs 1 & 2 through a hierarchical tunnel H-LSP by associating BSID1
   and BSID2 to H-LSP in order to use it respectively for LSP1 and LSP2 like this:

   A->B->C (incoming LSP1) --\                                    /-- Z->U (continuation of LSP1)
                              --> C->Y->Z (hierarchical H-LSP) -->
   D->E->C (incoming LSP2) --/                                    \-- Z->W (continuation of LSP2)

   In this example, how Z can determine which packets from LSP1 should continue to
   U and which packets from LSP2 should continue to W? A solution would be to keep
   the BSID1, respectively BSID2, for each packets belonging to LSP1 respectively
   LSP2 to help Z determine the next hop. So, for this purpose,would it be
   possible to add a flag to indicate that the BSID must be preserved, so that
   packets can pass through a hierarchical tunnel transparently?

Regards

Olivier

Le 18/03/2021 à 12:08, [email-masked] a écrit :
> _______________________________________________
> Pce mailing list
> [email-masked]
> 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
[email-masked] <mailto:[email-masked]>

---

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 19 Mar 2021 20:20:57 +0000

Hi all,

Overall Support WGLC. It's an important document in the world of SRTE, and the document goes to good lengths to describe the various scenarios and combinations. 

Only one question I have for the authors and WG, for any further clarification on the following text (section 4):

  The absence of TE-PATH-BINDING TLV in PCUpd message
   means that the PCE does not specify a binding value in which case the
   binding value allocation is governed by the PCC's local policy.

I find the "governed by PCC local policy" a bit too vague and could lead to implementation interop differences. Assuming a PCInitiated LSP that been established with a BSID: If the PCE wants to withdraw the binding SID , I interpret the document as the PCE would send a PCUpdate without the TLV, but the behaviour is now up to PCC as per that text. if the PCC local policy/implementation is to do nothing, how can the PCE explicitly force-remove the BSID with a PCUpdate? In a similar manner, If the PCE does not want to change the value but PCC local policy is to treat missing TLV as remove, then PCE should always send the TLV in every PCUpdate (which I'm okay with) which is not stated, otherwise the local policy/implementation may interpret it as a removal compared to an implementation which may interpret it as being okay to not send the TLV on every PCUpdate since there was "no change". 

In summary: might need a bit of a wording to further detail "PCE wishes to withdraw" case. 

Thanks! 
Andrew

On 2021-03-18, 7:09 AM, "Pce on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    Hi all,

    Thanks,

    Dhruv & Julien

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 22 Mar 2021 11:57:15 +0800

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. 
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: [email-masked] <[email-masked]> On Behalf Of
[email-masked]
Sent: Thursday, March 18, 2021 7:09 PM
To: [email-masked]
Cc: [email-masked]
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).

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.

---

From: tom petch <[email-masked]>
Date: Mon, 22 Mar 2021 12:02:21 +0000

From: Pce <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: 18 March 2021 11:08

Hi all,

<tp>
I find the terminology imprecise and in need of tightening up.

S.11.1.1 uses MPLS Label and MPLS Label Stack Entry as does RFC3032 which is as it should be.

Elsewhere the I-D uses binding label/SID without ever being precise about its meaning.  It needs defining  or expanding to binding MPLS label/SID or probably being replaced by something neater.

s.1 uses binding MPLS label; what is the difference?

Binding value is then defined which seems to me to make binding label/SID and unnecessary mouthful.

s.3 has binding label or SID as well as MPLS label binding

this section also uses 'MPLS label' - good - but then spoils it by using label unqualified

It then uses MPLS label entry which would appear to be a reference to an MPLS label stack entry

Likewise label stack entry would appear to mean MPLS label stack entry

s.4 uses MPLS label binding

The problem comes with loose terminology when e.g. a document is up for revision and future readers wonder why, if the same concept is being referred to, does the terminology keep changing, which sometimes just leads to a waste of time, other times to errors in implementation.

Since label has overtones of MPLS whereas SID is clearly SR, then I think you need a different term when you mean one or the other.  I think that 'binding value' as used in at least one place is a better choice, with an explanation thereof early on in the introduction. 'Binding value is used here to refer to an MPLS label or an IPv6 SID as appropriate'

Tom Petch

Thanks,

Dhruv & Julien

---

From: tom petch <[email-masked]>
Date: Mon, 22 Mar 2021 12:14:26 +0000

Separate to my other comments
________________________________________
From: Pce <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: 18 March 2021 11:08

Hi all,

<tp>
I am unclear how much is being requested of IANA here but ..

s.11.1.1 starts the registry at zero which is consistent with the rest of the I-D.  Is there any need to reserve the value of zero as something special?  Probably not but something to consider

TBD4 and TBD5 have almost identical Error-value which I think unhelpful.  The wording should be more distinctive IMHO.  If this is part of the Early Allocation request, then it is better to fix it now rather than getting into IANA in this form. Perhaps
'Unable to amend the..
'Unable to allocate a..
And along with TBD2  and TBD6, as in my separate e-mail, I find 'Binding label/SID' clumsy and would prefer a replacement such as 'Binding value'

Tom Petch

Thanks,

Dhruv & Julien

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 23 Mar 2021 10:17:47 -0000

Hi Julien, WG, authors.

Code point allocation: Is the request for all of the code points in the
document? What about the not-yet-allocated code point from
[I-D.ietf-pce-pcep-extension-for-pce-controller]. This spec can't be
implemented without it.

WG last call: I have a few questions/issues/nits below.

Best,
Adrian

== Questions / Issues ==

Abstract

What is the difference between "a Binding Segment Identifier (BSID)" and
a "binding Segment-ID (SID)"?

---

Abstract

"Such a binding label/SID"
This is the first use of "label". You need some context.

---

Abstract

   This document proposes
   an approach for reporting binding label/SID to Path Computation
   Element (PCE) for supporting PCE-based Traffic Engineering policies.

Who does the reporting?
Same in Section 1 top of page 4.

---

3.

   o  BT = 0: The binding value is an MPLS label carried in the format
      specified in [RFC5462] where only the label value is valid, and
      other fields MUST be considered invalid.  The Length MUST be set
      to 7.

I don't think that RFC 5462 is the right reference. That document simply
renames a field in the MPLS label stack entry.

So, are you carrying an MPLS label or an MPLS label stack entry? Either
is possible, although since you're only interested in the label, it
might be more normal to carry just the label value in the least
significant 20 bits of the binding value field. That would be consistent
with a Length of 7.

But, if you want to carry the full label stack entry (with the other
fields  ignored) then perhaps...
   o  BT = 0: The binding value is an MPLS label carried in an MPLS 
      label stack entry format as specified in [RFC3032] where only the
      label value is valid, and other fields MUST be ignored.  The
      Length MUST be set to 8.

This would be more consistent with:
   o  BT = 1: Similar to the case where BT is 0 except that all the
      fields on the MPLS label entry are set on transmission.  However,
      the receiver MAY choose to override TC, S, and TTL values
      according its local policy.  The Length MUST be set to 8.
But here you may want a little more clarity as:
   o  BT = 1: Similar to the case where BT is 0 except that all the
      fields of the MPLS label stack entry are set on transmission of
      the PCEP message containing the TLV.  A PCC receiver of this TLV 
      in a PCEP message MAY choose to override TC, S, and TTL values 
      according its local policy.  The Length MUST be set to 8.

But, at the bottom of the section...
   For the BT as 0, the 20 bits represent the MPLS
   label.  For the BT as 1, the 32-bits represent the label stack entry
   as per [RFC5462].
Which is going back on itself (and using the wrong reference).

Just make a decision on the meaning of BT=0 and make the text clean.

---

3.

I'm a bit puzzled as to why this document defines two flags for the 
Path Binding TLV Flags field, when this document clearly doesn't use or
depend on them.

In order to not make [I-D.ietf-spring-segment-routing-policy] a 
normative reference, perhaps you should not mention the specific bits,
create the registry (in 11.1.1) as empty, and simply not that 
[I-D.ietf-spring-segment-routing-policy] defines some flags.

(Obviously, [I-D.ietf-spring-segment-routing-policy] will need to make
assignments from the registry.)

---

4.

   Multiple TE-PATH-BINDING TLVs are allowed to be present in the same
   LSP object.  This signifies the presence of multiple binding SIDs for
   the given LSP.

If one of these contains a bad value, and a PCErr is sent according to 
the previous paragraph, what happens to all the other Binding Values?
Are they used or discarded?

---

4.

   For SRv6 BSIDs, it is RECOMMENDED to always explicitly specify the
   SRv6 Endpoint Behavior and SID Structure in the TE-PATH-BINDING TLV
   by setting the BT (Binding Type) to 3, instead of 2.  The choice of
   interpreting SRv6 Endpoint Behavior and SID Structure when none is
   explicitly specified is left up to the implementation.

I puzzled about the alternative to "RECOMMENDED".  I wondered if the
second sentence was meant to offer that guidance, but perhaps it is
intended to only to cover the case when no Path Binding TLV is present.
Two concepts in one paragraph?

---

4.

   If a PCC wishes to withdraw or modify a previously reported binding
   value, it MUST send a PCRpt message without any TE-PATH-BINDING TLV
   or with the TE-PATH-BINDING TLV containing the new binding value
   respectively.

   If a PCE wishes to modify a previously requested binding value, it
   MUST send a PCUpd message with TE-PATH-BINDING TLV containing the new
   binding value.  The absence of TE-PATH-BINDING TLV in PCUpd message
   means that the PCE does not specify a binding value in which case the
   binding value allocation is governed by the PCC's local policy.

How does this work if multiple binding values have been assigned by 
using multiple TE-PATH-BINDING TLVs? Suppose, having done that, it is
the intention to withdraw one of the binding values but leave the others
in place. Should the message making the change contain all the TLVs 
except the one being withdrawn?

   If a PCC receives a valid binding value from a PCE which is different
   than the current binding value, it MUST try to allocate the new
   value.  If the new binding value is successfully allocated, the PCC
   MUST report the new value to the PCE.  Otherwise, it MUST send a
   PCErr message with Error-Type = TBD2 ("Binding label/SID failure")
   and Error Value = TBD4 ("Unable to allocate the specified label/
   SID").

And in this failure case, what is the residual state? Is the old value
still in place, or is no value in place?

== A whole pile of nits and minor issues ==

Abstract

s/a BSID to RSVP-TE/a BSID to an RSVP-TE/
s/or binding Segment-/or a binding Segment-/
s/to SR Traffic/to an SR Traffic/

---

Abstract

"This document proposes". You need to word this to be appropriate for an
RFC. Thus, "This document specifies".

---

Abstract

s/for supporting/to support/

---

Requirements Language should move to Section 2.

---

1.

Expand PCE on first use

---

1.

s/through a network that are/through a network where those paths are/
s/[RFC8402], Binding/[RFC8402], a Binding/
s/an Segment Routed/a Segment Routed/
s/equal to BSID/equal to a BSID/
s/interface or tunnels/interface or tunnel/
s/as segments/as a segment/
s/extension to PCEP that allows/extensions to PCEP that allow/
s/PCEP extension to setup/PCEP extensions to set up/

---

1. Please expand "LSP" on first use

---

1.

   The PCEP extension to setup and maintain SR-TE
   paths is specified in [RFC8664].

   [RFC8664] provides a mechanism for a network controller (acting as a
   PCE) to instantiate candidate paths for an SR Policy onto a head-end
   node (acting as a PCC) using PCEP.

Do you need both of these sentences?

---

1.

s/"Binding label/SID has local"/"A binding label/SID has local"/
s/the following diagram/Figure 1/  (you can use an xref)
s/"In IP/MPLS WAN"/"In the IP/MPLS WAN"/
s/setup using/set up using/

---

1.

   Binding value means either MPLS label or SID
   throughout this document.

This might read better as:

   Throughout this document, the term "binding value" means either an
   MPLS label or SID.

---

2.

The following are not used in this document and don't need to be in the
list:
   LER
   LSR

The following are not used in later sections of this document and don't
need to be in the list:
   SRGB
   SRLB

---

3.

s/in the figure below/in Figure 3/
s/in ([RFC8231])/in [RFC8231]/
s/type of this TLV is to be allocated by IANA/type of this TLV is TBD1/

---

3.

For Binding Type (BT), a forward pointer to 11.1.1 would be nice.

---

3.1.

   Carried as the Binding Value in the TE-PATH-BINDING TLV when the BT
   is set to 3.  Applicable for SRv6 Binding SIDs
   [I-D.ietf-spring-srv6-network-programming].

These need to be sentences with a subject.
I think you can update to [RFC8986].

---

3.1

Figure 4 should be numbered Figure 3.
The text should contain an explicit mention of Figure 3.
The text should mention each of the fields in the figure.

---

3.1
   Endpoint Behavior: 2 octets.  The Endpoint Behavior code point for
   this SRv6 SID as defined in section 9.2 of
   [I-D.ietf-spring-srv6-network-programming].
There is no section 9.2 in RFC 8986. You're probably after section 10.2.
But is that the right thing to do? Don't you want to point at the IANA
registry so that you embrace any future values as well?

---

3.1
   LB Length: 1 octet.  SRv6 SID Locator Block length in bits.

   LN Length: 1 octet.  SRv6 SID Locator Node length in bits.

   Function Length: 1 octet.  SRv6 SID Function length in bits.

   Argument Length: 1 octet.  SRv6 SID Arguments length in bits.

It is unclear what these lengths refer to in the context of this binding
value. Probably you can just provide pointers to where the meaning is
found.

---

4.
s/([RFC5440])/[RFC5440]/
s/message, PCE MUST/message, the PCE MUST/
s/MUST send the PCErr/MUST send a PCErr/

---

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.
In order to avoid confusion, I suggest s/may do/does/

---

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.

"it may do so" is probably "it instructs the PCC"

---

4.

s/receives TE-PATH-BINDING TLV/receives a TE-PATH-BINDING TLV/
s/other than LSP object/other than an LSP object/
s/It may do so by sending a PCUpd/It does so by sending a PCUpd/

---

5.

"a PCErr message is sent"  Who does the sending? "the receiver"?

---

6.

s/for SRv6 SID./for an SRv6 SID./

---

7.

s/This section specify/This section specifies/

---

7.

"allocate the binding label" Do you mean "binding label/SID"?
The rest of the paragraph seems a little inconsistent on that.
Perhaps, also, the section title is wrong.

---

7.

s/before PCE could/before the PCE can/

---

7.

      The TLV in LSP object identifies what should be
      allocated, such as Binding label/SID.

Suggest to remove this sentence as superfluous with following text.

---

7.

OLD
   o  to let the PCC allocates the binding label/SID, a PCE could set
      P=0 and empty TE-PATH-BINDING TLV ( i.e., no binding value is
      specified) in the LSP object in PCInitiate/PCUpd message.
NEW
   o  to let the PCC allocates the binding label/SID, a PCE could set
      P=0 and include an empty TE-PATH-BINDING TLV (i.e., no binding 
      value is specified) in the LSP object in PCInitiate/PCUpd message.
END

Similarly

OLD
   o  a PCC could request that the PCE allocate the binding label/SID by
      setting P=1, D=1, and empty TE-PATH-BINDING TLV in PCRpt message.
NEW
   o  a PCC could request that the PCE allocate the binding label/SID by
      setting P=1, D=1, and including an empty TE-PATH-BINDING TLV in
      PCRpt message.
END

---

7.

Bullets following "Note that,..." should all start with capital letters
so that multi-sentence bullet text is not confused.

---

7.

   o  if both peers have not exchanged the PCECC capabilities as per
      [I-D.ietf-pce-pcep-extension-for-pce-controller] and it receives
      P=1 in the LSP object, it needs to act as per
      [I-D.ietf-pce-pcep-extension-for-pce-controller]:

What is "it"?

---

7.

      *  Send a PCErr message with Error-Type=19 (Invalid Operation) and
         Error-Value=TBD (Attempted PCECC operations when PCECC
         capability was not advertised)

I understand this to mean to use the Error-Value defined in 
[I-D.ietf-pce-pcep-extension-for-pce-controller] and marked in that 
document as TBD3.

I suggest you use

      *  Send a PCErr message with Error-Type=19 ("Invalid Operation") 
         and Error-Value=TBD7 ("Attempted PCECC operations when PCECC
         capability was not advertised"). [RFC-EDITOR: Please replace
         TBD7 with the value assigned by IANA for this Error-Value,
         indicated by "TBD3" in [I-D.ietf-pce-pcep-extension-for-pce-
         controller].]

---

7.
   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 from
   the PCC-controlled label space with P=0 as described in Section 4.
s/PCE would/The PCE can/ (twice)

---

9.

s/rouge/rogue/
s/other LSPs that uses/other LSP that uses/

---

11.1.1

The two new registries need to have ranges specified so that IANA knows
what new values can be assigned. 

---

I think the affiliations of some of your authors and contributors may
be out of date.

---

From: <[email-masked]>
Date: Thu, 25 Mar 2021 17:43:09 +0100

Hi Adrian,

Thanks a lot for your thorough review.

Your comment about draft-ietf-pce-pcep-extension-for-pce-controller is
legitimate. Good news: it's in the RFC Editor queue
(https://www.rfc-editor.org/current_queue.php#draft-ietf-pce-pcep-extension-for-pce-controller)
and associated code points have already been allocated
(https://www.iana.org/assignments/pcep/pcep.xhtml#pcecc-capability).

Cheers,

Dhruv & Julien

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 26 Mar 2021 02:26:33 +0000

Hi Adrian,

Long time no see! Thanks for your valuable comments!  :)

It takes few days to address them, LOL. The latest revision has updated, see
https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-08.txt
https://github.com/dhruvdhody/ietf/blob/master/draft-ietf-pce-binding-label-sid-08.xml

Diff is attached.
Please see my reply inline.

Respect,
Cheng

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Tuesday, March 23, 2021 6:18 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi Julien, WG, authors.

Code point allocation: Is the request for all of the code points in the document? What about the not-yet-allocated code point from [I-D.ietf-pce-pcep-extension-for-pce-controller]. This spec can't be implemented without it.

Best,
Adrian

== Questions / Issues ==

Abstract

What is the difference between "a Binding Segment Identifier (BSID)" and a "binding Segment-ID (SID)"?

---

[Cheng] Removed Segment-ID

Abstract

---

[Cheng] Added - "This document specifies the binding value as an MPLS label or Segment Identifier."

Abstract

   This document proposes

Who does the reporting?

[Cheng] Updated to identify PCC.  

---

3.

I don't think that RFC 5462 is the right reference. That document simply renames a field in the MPLS label stack entry.

So, are you carrying an MPLS label or an MPLS label stack entry? Either is possible, although since you're only interested in the label, it might be more normal to carry just the label value in the least significant 20 bits of the binding value field. That would be consistent with a Length of 7.

But, if you want to carry the full label stack entry (with the other fields  ignored) then perhaps...
   o  BT = 0: The binding value is an MPLS label carried in an MPLS 
      label stack entry format as specified in [RFC3032] where only the
      label value is valid, and other fields MUST be ignored.  The
      Length MUST be set to 8.

---

[Cheng] How about this - 

   o  BT = 0: The binding value is a 20-bit MPLS label value.  The TLV
      is padded to 4-bytes alignment.  The Length MUST be set to 7 and
      first 20 bits are used to encode the MPLS label value.

   o  BT = 1: The binding value is a 32-bit MPLS label stack entry as
      per [RFC3032] with Label, TC [RFC5462], S, and TTL values encoded.
      Note that the receiver MAY choose to override TC, S, and TTL
      values according to its local policy.  The Length MUST be set to 8.

3.

I'm a bit puzzled as to why this document defines two flags for the Path Binding TLV Flags field, when this document clearly doesn't use or depend on them.

In order to not make [I-D.ietf-spring-segment-routing-policy] a normative reference, perhaps you should not mention the specific bits, create the registry (in 11.1.1) as empty, and simply not that [I-D.ietf-spring-segment-routing-policy] defines some flags.

(Obviously, [I-D.ietf-spring-segment-routing-policy] will need to make assignments from the registry.)

---
[Cheng] The idea was to make it consistent with IDR WG I-D [draft-ietf-idr-segment-routing-te-policy]. 
One option could be to move this to the SR-policy-related PCE WG I-D [draft-ietf-pce-segment-routing-policy-cp]. 
I have kept this open for now for further discussion.

4.

If one of these contains a bad value, and a PCErr is sent according to the previous paragraph, what happens to all the other Binding Values?
Are they used or discarded?

[Cheng] They should not be impacted. I have added this - 

   In case of multiple TE-PATH-BINDING TLVs, all
   instances of TE-PATH-BINDING TLVs MUST always be included in the LSP
   object.  In case of an error, a PCErr message MAY include the
   offending TE-PATH-BINDING TLV in the PCEP-ERROR object.

---

4.

I puzzled about the alternative to "RECOMMENDED".  I wondered if the second sentence was meant to offer that guidance, but perhaps it is intended to only to cover the case when no Path Binding TLV is present.
Two concepts in one paragraph?

---
[Cheng]
The idea was to say that while BT=2 (just IPv6 address) for BSID is allowed, there are older implementations, but BT=3 SHOULD be proffered which requires explicit SID structure and behavior to be explicitly encoded. 
It is not about when no Path Binding TLV is present.
Do you have a better way to put this?

4.

How does this work if multiple binding values have been assigned by using multiple TE-PATH-BINDING TLVs? Suppose, having done that, it is the intention to withdraw one of the binding values but leave the others in place. Should the message making the change contain all the TLVs except the one being withdrawn?

And in this failure case, what is the residual state? Is the old value still in place, or is no value in place?

[Cheng] It has been specified that all instances of TE-PATH-BINDING TLVs need to be included and the offending TE-PATH-BINDING TLV can be included in the PCEP-ERROR object. 
Any suggestion to make this clearer?

Abstract

s/a BSID to RSVP-TE/a BSID to an RSVP-TE/ s/or binding Segment-/or a binding Segment-/ s/to SR Traffic/to an SR Traffic/

---

Abstract

"This document proposes". You need to word this to be appropriate for an RFC. Thus, "This document specifies".

---

Abstract

---

---

[Cheng] Updated

1.

Expand PCE on first use

[Cheng]Done. BTW PCE has a * in https://www.rfc-editor.org/materials/abbrev.expansion.txt

---

1.

s/through a network that are/through a network where those paths are/ s/[RFC8402], Binding/[RFC8402], a Binding/ s/an Segment Routed/a Segment Routed/ s/equal to BSID/equal to a BSID/ s/interface or tunnels/interface or tunnel/ s/as segments/as a segment/ s/extension to PCEP that allows/extensions to PCEP that allow/ s/PCEP extension to setup/PCEP extensions to set up/

---

---

1.

---

1.

s/"Binding label/SID has local"/"A binding label/SID has local"/ s/the following diagram/Figure 1/  (you can use an xref) s/"In IP/MPLS WAN"/"In the IP/MPLS WAN"/ s/setup using/set up using/

---

1.

---

[Cheng] Updated for the above comments.

2.

The following are not used in later sections of this document and don't need to be in the list:
   SRGB
   SRLB

---

3.

---

3.

---

3.1.

---

3.1

---

3.1
But is that the right thing to do? Don't you want to point at the IANA registry so that you embrace any future values as well?

---
[Cheng] Updated for the above comments.

3.1

It is unclear what these lengths refer to in the context of this binding value. Probably you can just provide pointers to where the meaning is found.

---

[Cheng] Added - "The following fields are used to advertise the length of each individual part of the SRv6 SID as defined in [RFC8986]."

4.
s/([RFC5440])/[RFC5440]/
s/message, PCE MUST/message, the PCE MUST/ s/MUST send the PCErr/MUST send a PCErr/

---

[Cheng] Updated

4.

[Cheng]Ignoring, updated as per the below suggestion.

---

4.

---

[Cheng] Updated (ignored the 3rd nit below)

4.

s/receives TE-PATH-BINDING TLV/receives a TE-PATH-BINDING TLV/ s/other than LSP object/other than an LSP object/ s/It may do so by sending a PCUpd/It does so by sending a PCUpd/

---

5.

---

6.

---

7.

---

7.

---

7.

---

[Cheng]Updated

7.

---

[Cheng] No following text :)
I suggest changing it to - "The TE-PATH-BINDING TLV in the LSP object identifies that the allocation is for Binding label/SID."

7.

OLD

Similarly

OLD

---

7.

Bullets following "Note that,..." should all start with capital letters so that multi-sentence bullet text is not confused.

---

7.

What is "it"?

[Cheng] Changed the first "it" to "a PCEP peer".

---

7.

I understand this to mean to use the Error-Value defined in [I-D.ietf-pce-pcep-extension-for-pce-controller] and marked in that document as TBD3.

I suggest you use

---
[Cheng] IANA has made the allocation as the I-D is in the RFC-Editor queue. 
Perhaps we can use the value directly as per https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object?

7.

---

9.

s/rouge/rogue/

---

11.1.1

The two new registries need to have ranges specified so that IANA knows what new values can be assigned. 

---

I think the affiliations of some of your authors and contributors may be out of date.

[Cheng]Updated

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 26 Mar 2021 02:46:08 +0000

Hi Aijun,

Many thanks for your comments! Please see my reply inline. The diff is attached.

Respect,
Cheng

-----Original Message-----
From: Aijun Wang [mailto:[email-masked]] 
Sent: Monday, March 22, 2021 11:57 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
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: [email-masked] <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, March 18, 2021 7:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi all,

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.

Thanks,

Dhruv & Julien

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 26 Mar 2021 02:49:33 +0000

Hi Andrew, 

Thanks for your comments, please see my reply inline.

Also, the diff is attached.

Respect,
Cheng

-----Original Message-----
From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:[email-masked]] 
Sent: Saturday, March 20, 2021 4:21 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi all,

[Cheng] You are correct, there was some issues with multiple TE-PATH-BINDING TLV. This has been updated. See the diff.

The above text has been updated to - 

   The absence of TE-PATH-BINDING TLV in PCUpd message means that the
   PCE does not specify a binding value in which case any previous
   allocated binding values are withdraw.

Further, the PCC's local policy aspect has been seperated out as - 

   In the absence of any instruction from the PCE, the PCC's local
   policy dictates how the binding allocations are made for a given LSP.

Thanks!

Thanks! 
Andrew

    Hi all,

    Thanks,

    Dhruv & Julien

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 26 Mar 2021 03:08:48 +0000

Hi Olivier,

Many thanks for your comments, please see my reply inline.

Respect,
Cheng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, March 20, 2021 12:39 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi all,

I support adoption of this draft, but I have a certain number of questions for the authors:

[Cheng] I dont think there is any coupling between source IP address and BSID in SPRING RFCs. 
A BSID is availaible on all interfaces.   

[Cheng] Some more text has been added to describe the handling of multiple TE-PATH-BINDING TLVs. 
Hope that clarifies the above queries. Please check the diff.

[Cheng]BSIDs are not flooded in the IGP as per the current RFCs in LSR.

[Cheng] This is out of scope of this I-D also this would be against the BSID handling in SPRING. 
It could be discussed in draft-ietf-pce-stateful-interdomain perhaps?

If I understand correctly, the BSID1 should represent Y-Z-U, and BSID2 represents Y-Z-W, so, an node C, the packets will be forwarded into specific LSP according to the BSID.

Regards

Olivier

Le 18/03/2021 à 12:08, [email-masked] a écrit :
> feedback, whatever it is, using the PCE mailing list. This WGLC will 
> end on Thursday April 1st (no kidding).
>
>
> handling the protocol entities defined by the code points (henceforth 
> called "specifications") must be adequately described in an 
> Internet-Draft.
> 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
>
>
> ______________________________________________________________________
> ___________________________________________________
>
> 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.

Olivier Dugeon

fixe : +33 2 96 07 28 80

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 26 Mar 2021 03:12:49 +0000

Hi Tom,

Many thanks for your comments. Please see my reply inline.

Respect,
Cheng

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of tom petch
Sent: Monday, March 22, 2021 8:14 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi all,

<tp>

[Cheng] WG/existing implemntations are happy with 0; I dont see a strong reason to change that.

TBD4 and TBD5 have almost identical Error-value which I think unhelpful.  The wording should be more distinctive IMHO.  If this is part of the Early Allocation request, then it is better to fix it now rather than getting into IANA in this form. Perhaps 'Unable to amend the..
'Unable to allocate a..
And along with TBD2  and TBD6, as in my separate e-mail, I find 'Binding label/SID' clumsy and would prefer a replacement such as 'Binding value'

[Cheng] Changed to - 
TBD4: Unable to allocate the specified binding value
TBD5: Unable to allocate a new binding label/SID
Thanks!

Tom Petch

Thanks,

Dhruv & Julien

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 26 Mar 2021 03:14:20 +0000

Hi Tom,

Thanks, please see inline.

Cheng

-----Original Message-----
From: tom petch [mailto:[email-masked]] 
Sent: Monday, March 22, 2021 8:02 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi all,

<tp>

[Cheng]I have added - 

In this document, binding label/SID is used to generalize the allocation of binding value for both SR and non-SR paths.

Removed - 
- binding MPLS label
- binding label or SID   
- MPLS label binding

Made some other correction. Hope the above clarification and cleanup is enough. 

Also,
- Binding value is the term when refering to the specified value in the TLV 
- binding label/SID is used in the generic sense 
I find this to be useful distinction. 

Thanks! 
Cheng

Tom Petch

Thanks,

Dhruv & Julien

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 26 Mar 2021 06:41:30 +0000

Oh, Adrian, all, 

some update for comment 4, Regarding multiple TE-PATH-BINDING TLVs, we have updated the operation rules as follow.

   In case of multiple TE-PATH-BINDING TLVs, all
   existing instances of TE-PATH-BINDING TLVs MUST always be included in
   the LSP object.  In case of an error condition, the whole message is
   rejected and the resulting PCErr message MAY include the offending
   TE-PATH-BINDING TLV in the PCEP-ERROR object.

Also, the draft has been updated, and the latest diff is here: 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

Sorry for sending the internal diff version when we handle multiple comments:(

Cheng

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Chengli (Cheng Li)
Sent: Friday, March 26, 2021 10:27 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi Adrian,

It takes few days to address them, LOL. The latest revision has updated, see https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-08.txt
https://github.com/dhruvdhody/ietf/blob/master/draft-ietf-pce-binding-label-sid-08.xml

Diff is attached.

Respect,
Cheng

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Tuesday, March 23, 2021 6:18 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi Julien, WG, authors.

Best,
Adrian

== Questions / Issues ==

Abstract

---

Abstract

---

Abstract

   This document proposes

Who does the reporting?

---

3.

---

[Cheng] How about this - 

3.

---

4.

---

4.

---
[Cheng]

4.

Abstract

---

Abstract

---

Abstract

---

---

[Cheng] Updated

1.

Expand PCE on first use

---

1.

---

---

1.

---

1.

---

1.

---

2.

---

3.

---

3.

---

3.1.

---

3.1

---

3.1

---

3.1

---

4.
s/([RFC5440])/[RFC5440]/

---

[Cheng] Updated

4.

---

4.

---

4.

---

5.

---

6.

---

7.

---

7.

---

7.

---

[Cheng]Updated

7.

---

7.

OLD

Similarly

OLD

---

7.

---

7.

What is "it"?

---

7.

I suggest you use

---

7.

---

9.

s/rouge/rogue/

---

11.1.1

---

[Cheng]Updated

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 26 Mar 2021 06:59:21 +0000

Hi Tom, 

Sorry for sending the error diff.

The latest diff is here 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

Also, Julien has replied to Adrian about the IANA allocation comments. 
The IANA early allocation will be issued without error type at this time.

Thanks,
Cheng

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of tom petch
Sent: Monday, March 22, 2021 8:14 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi all,

<tp>

Tom Petch

Thanks,

Dhruv & Julien

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 26 Mar 2021 07:01:13 +0000

To all,

The latest diff of BSID draft is 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

Sorry for using the wrong diff file.

Thanks,
Cheng

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Chengli (Cheng Li)
Sent: Friday, March 26, 2021 10:46 AM
To: Aijun Wang <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi Aijun,

Respect,
Cheng

-----Original Message-----
From: Aijun Wang [mailto:[email-masked]] 
Sent: Monday, March 22, 2021 11:57 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi, 

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, March 18, 2021 7:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi all,

Thanks,

Dhruv & Julien

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 26 Mar 2021 11:22:55 -0000

Hi Cheng!

This is good progress, thanks.

I have cut down to the points that are still open.

Nothing we need to fight about 😊

Best,
Adrian

>> is possible, although since you're only interested in the label, it might be
>> more normal to carry just the label value in the least significant 20 bits
>> of the binding value field. That would be consistent with a Length of 7.
>>

OK. This is clear. I think you just need to look through the other mentions of BT=0 and BT=1 to make sure they match with this.

>> 3.
>>
>> I'm a bit puzzled as to why this document defines two flags for the Path Binding TLV 
>> Flags field, when this document clearly doesn't use or depend on them.
>>
>> In order to not make [I-D.ietf-spring-segment-routing-policy] a normative reference, perhaps
>> you should not mention the specific bits, create the registry (in 11.1.1) as empty, and simply
>> not that [I-D.ietf-spring-segment-routing-policy] defines some flags.
>>

To be clear, I was suggesting:
- this document creates and defines the registry
- the documents that need codepoints are responsible for requesting allocation of codepoints

>> If one of these contains a bad value, and a PCErr is sent according to the previous
>> paragraph, what happens to all the other Binding Values?

I think maybe I wasn't clear.
Suppose the LSP object contains three TE-PATH-BINDING TLVs (TLV1, TLV2, and TLV3)
Suppose that TLV3 contains a bad value.
That means a PCErr will be sent with PCEP-ERROR and that MAY contain the offending TLV3.
OK so far.
Now, what happens to TLV1 and TLV2?
    Are they processed and used by the receiver?
      Or
    Are they all rejected because the received message has been rejected?
Personally, I think you should reject the whole message because this makes the case of modifying previous values a lot easier (see a later point).

>> I puzzled about the alternative to "RECOMMENDED".  I wondered if the second
>> sentence was meant to offer that guidance, but perhaps it is intended to only
>> to cover the case when no Path Binding TLV is present.
> The idea was to say that while BT=2 (just IPv6 address) for BSID is allowed, there
> are older implementations, but BT=3 SHOULD be proffered which requires explicit
> SID structure and behavior to be explicitly encoded. 

Ah, and possibly "ouch".
You are actually saying that BT=2 is only present to support pre-standard implementations. That's actually not a good reason to put something in a standard.

How about...
   For SRv6 BSIDs, it is RECOMMENDED to always explicitly specify the
   SRv6 Endpoint Behavior and SID Structure in the TE-PATH-BINDING TLV
   by setting the BT (Binding Type) to 3.  This enables the sender to have
   control of the SRv6 Endpoint Behavior and SID Structure.  A sender MAY
   choose to set the BT to 2, in which case the receiving implementation
   chooses how to interpret the SRv6 Endpoint Behavior and SID Structure
   according to local configuration.

>> using multiple TE-PATH-BINDING TLVs? Suppose, having done that, it
>> is the intention to withdraw one of the binding values but leave the
>> others in place. Should the message making the change contain all the 
>> TLVs except the one being withdrawn?
>>
> [Cheng] It has been specified that all instances of TE-PATH-BINDING TLVs
> need to be included and the offending TE-PATH-BINDING TLV can be
> included in the PCEP-ERROR object. 
>

There are two separate issues here. Sorry for including them in one comment.

First. When you send a new PCRpt it completely overwrites any previous PCRpt and so you must include all of the TE-PATH-BINDING TLVs you want to apply form now on. So...
OLD
   If a PCC wishes to withdraw or modify a previously reported binding
   value, it MUST send a PCRpt message without any TE-PATH-BINDING TLV
   or with the TE-PATH-BINDING TLV containing the new binding value
   respectively.

   If a PCE wishes to modify a previously requested binding value, it
   MUST send a PCUpd message with TE-PATH-BINDING TLV containing the new
   binding value.  The absence of TE-PATH-BINDING TLV in PCUpd message
   means that the PCE does not specify a binding value in which case the
   binding value allocation is governed by the PCC's local policy.
NEW
   If a PCC wishes to withdraw all previously reported binding values, it
   MUST send a PCRpt message without any TE-PATH-BINDING TLV.  If a
   PCC wishes to modify any or all previously reported binding values, it
   MUST send a PCRpt message containing TE-PATH-BINDING TLVs 
   containing all the binding values that apply from that point on.

   If a PCE wishes to modify a previously requested binding value, it
   MUST send a PCUpd message with TE-PATH-BINDING TLVs containing
   all the binding values that apply from that point on.  The absence of
   TE-PATH-BINDING TLV in PCUpd message means that the PCE does 
   not specify a binding value in which case the binding value allocation
   is governed by the PCC's local policy, and the PCC MAY continue to
   use the previously allocated values.
END

Second. As discussed in a previous point, you have to describe what happens when a message with multiple TE-PATH-BINDING TLVs contains one that is in error. Is the whole message rejected, or do the good TLVs still get applied?  If the message is rejected, presumably the previously allocated values still apply. If the good TLVs still get actioned, presumably any that are not continued in the new message are removed. You can handle this by:
- addressing the issue as in the previous point
- putting a note here something like...

   As previously noted, if a message that is intended to modify a previously
   allocated binding value contains a TE-PATH-BINDING TLV with a bad 
   value, .... <fill in the details>

> [Cheng]Done. BTW PCE has a * in https://www.rfc-editor.org/materials/abbrev.expansion.txt

Oh, that's new. My apologies.

> I suggest changing it to - "The TE-PATH-BINDING TLV in the LSP object identifies
> that the allocation is for Binding label/SID."

Sorry, I meant "with the text that follows in the next sentences of the document."

The document had...

     The TLV in LSP object identifies what should be
      allocated, such as Binding label/SID.  A PCC would set this bit to
      1 and include a TE-PATH-BINDING TLV in the LSP object to request
      for allocation of Binding label/SID by the PCE in the PCEP
      message.  A PCE would also set this bit to 1 and include a TE-
      PATH-BINDING TLV to indicate that the Binding label/SID is
      allocated by PCE and encoded in the PCEP message towards PCC.
      Further, a PCE would set this bit to 0 and include a TE-PATH-
      BINDING TLV in the LSP object to indicate that the Binding label/
      SID should be allocated by the PCC as described in Section 4.

It's not important, but my point was that the first sentence is redundant.

>> I understand this to mean to use the Error-Value defined in [I-D.ietf-
>> pce-pcep-extension-for-pce-controller] and marked in that document
>> as TBD3.

[snip]

> Perhaps we can use the value directly as per https://www.iana.org/
> assignments/pcep/pcep.xhtml#pcep-error-object?

It is slightly premature to use that value, but I think it is safe to do. So, yes, put the actual value in the text.

---

From: <[email-masked]>
Date: Fri, 26 Mar 2021 15:53:41 +0100

Hi Tom,

As agreed with the authors, we'll proceed with the early allocation
request by leaving the error codes pending upcoming updates (i.e.
request allocation for PCEP TLV and LSP object flags). This will leave
you some time to find an agreement on the final wording of the error
messages.

Thank you for your careful review,

Dhruv & Julien

---

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 26 Mar 2021 18:42:19 +0000

Hi Cheng,

Thanks for clarifying the text in the document. Diff content looks good to me, much clearer. Consider my comments resolved.

Thanks!
Andrew

On 2021-03-25, 10:49 PM, "Pce on behalf of Chengli (Cheng Li)" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Andrew, 

    Respect,
    Cheng

    -----Original Message-----
    From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:[email-masked]] 
    Sent: Saturday, March 20, 2021 4:21 AM
    To: [email-masked]; [email-masked]
    Cc: [email-masked]
    Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

    Hi all,

    Thanks!

    Thanks! 
    Andrew

        Hi all,

        Thanks,

        Dhruv & Julien

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Sat, 27 Mar 2021 01:45:26 +0000

Thanks again for your help!

Cheng

-----Original Message-----
From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:[email-masked]] 
Sent: Saturday, March 27, 2021 2:42 AM
To: Chengli (Cheng Li) <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi Cheng,

Thanks!
Andrew

    Hi Andrew, 

    Respect,
    Cheng

    -----Original Message-----
    From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:[email-masked]] 
    Sent: Saturday, March 20, 2021 4:21 AM
    To: [email-masked]; [email-masked]
    Cc: [email-masked]
    Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

    Hi all,

    Thanks!

    Thanks! 
    Andrew

        Hi all,

        Thanks,

        Dhruv & Julien

---

From: tom petch <[email-masked]>
Date: Sat, 27 Mar 2021 12:02:56 +0000

From: Pce <[email-masked]> on behalf of Adrian Farrel <[email-masked]>
Sent: 23 March 2021 10:17
To: [email-masked]; [email-masked]

<one comment inline>

Hi Julien, WG, authors.

Best,
Adrian

== Questions / Issues ==

Abstract

Abstract

<tp>
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
---

Abstract

   This document proposes

Who does the reporting?

---

3.

---

3.

---

4.

---

4.

---

4.

Abstract

---

Abstract

---

Abstract

---

---

1.

Expand PCE on first use

---

1.

---

---

1.

---

1.

---

1.

---

2.

---

3.

---

3.

---

3.1.

---

3.1

---

3.1

---

3.1

---

4.
s/([RFC5440])/[RFC5440]/

---

4.

---

4.

---

4.

---

5.

---

6.

---

7.

---

7.

---

7.

---

7.

---

7.

OLD

Similarly

OLD

---

7.

---

7.

What is "it"?

---

7.

I suggest you use

---

7.

---

9.

s/rouge/rogue/

---

11.1.1

---

---

From: tom petch <[email-masked]>
Date: Sat, 27 Mar 2021 12:10:14 +0000

From: Chengli (Cheng Li) <[email-masked]>
Sent: 26 March 2021 03:12

Hi Tom,

<tp>

Yes, on the use of zero, that was just a passing thought.

On terminology, as in my other e-mail, and as is implied in Adrian's comments, I think 
binding label/SID an unsatisfactory term, overloaded with semantics.  Elsewhere you use 'binding value ' and I see no reason not to use that throughout with an explanation up front as to what it means.

Tom Petch

Respect,
Cheng

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of tom petch
Sent: Monday, March 22, 2021 8:14 PM

Hi all,

<tp>

[Cheng] Changed to -

Tom Petch

Thanks,

Dhruv & Julien

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

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 27 Mar 2021 13:40:10 -0400

I support WG LC advancement of this draft for publication.

I see there are a lot of comments related to a mix of verbiage related to
MPLS label binding and Binding label SID confusion.

Few comments.

The draft title states “carrying binding label/sid in PCE based networks”

In the abstract it states it is possible to associate a BSID with a RSVP
signaled path.

I don’t recall any RSVP extension to support concept of BSID usage on an
active Candidate Path option ERO.  Can you refer me to the RFC that states
how BSID is used with RSVP TE.

For more clarity with this draft can we replace

s/TE/s/SR as TE nomenclature refers to RSVP-TE and does add confusion where
SR is SR.  When mentioned traffic engineered path please spell out or say
SR path for clarity.

Also the “TE-PATH-BINDING TLV” can we change to “SR-PATH-BINDING TLV”.

The word “binding” is very confusing as it’s used interchangeably with
label binding and binding SID.

So I am thinking a more appropriate name for the TLV would be “SR-TE-BSID
TLV”.  Makes it clear and concise the TLV is for SR-TE.

Kind Regards

Gyan

On Fri, Mar 26, 2021 at 9:45 PM Chengli (Cheng Li) <[email-masked]> wrote:

> Thanks for clarifying the text in the document. Diff content looks good to
> me, much clearer. Consider my comments resolved.
>
> Thanks!
> Andrew
>
> On 2021-03-25, 10:49 PM, "Pce on behalf of Chengli (Cheng Li)" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     Hi Andrew,
>
>     Subject: Re: [Pce] WG Last Call for
> draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
>
>     Hi all,
>
>     Overall Support WGLC. It's an important document in the world of SRTE,
> and the document goes to good lengths to describe the various scenarios and
> combinations.
>
>     Only one question I have for the authors and WG, for any further
> clarification on the following text (section 4):
>
>
>     I find the "governed by PCC local policy" a bit too vague and could
> lead to implementation interop differences. Assuming a PCInitiated LSP that
> been established with a BSID: If the PCE wants to withdraw the binding SID
> , I interpret the document as the PCE would send a PCUpdate without the
> TLV, but the behaviour is now up to PCC as per that text. if the PCC local
> policy/implementation is to do nothing, how can the PCE explicitly
> force-remove the BSID with a PCUpdate? In a similar manner, If the PCE does
> not want to change the value but PCC local policy is to treat missing TLV
> as remove, then PCE should always send the TLV in every PCUpdate (which I'm
> okay with) which is not stated, otherwise the local policy/implementation
> may interpret it as a removal compared to an implementation which may
> interpret it as being okay to not send the TLV on every PCUpdate since
> there was "no change".
>
>     [Cheng] You are correct, there was some issues with multiple
> TE-PATH-BINDING TLV. This has been updated. See the diff.
>
>     On 2021-03-18, 7:09 AM, "Pce on behalf of [email-masked]" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>         Hi all,
>
> 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,
> privileged information that may be protected by law;
>         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.
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Siva Sivabalan <[email-masked]>
Date: Sat, 27 Mar 2021 15:05:05 -0400

Hi Gyan,

BSID can be allocated for RSVP-TE as well, and yes, there are use-cases for
that. The proposed PCEP extension is equally applicable to both SR-TE and
RSVP-TE.

Thanks,
Siva

On Sat, Mar 27, 2021 at 1:40 PM Gyan Mishra <[email-masked]> wrote:

> s/TE/s/SR as TE nomenclature refers to RSVP-TE and does add confusion
> where SR is SR.  When mentioned traffic engineered path please spell out or
> say SR path for clarity.
>
>> Thanks for clarifying the text in the document. Diff content looks good
>> to me, much clearer. Consider my comments resolved.
>>
>> Thanks!
>> Andrew
>>
>>     Overall Support WGLC. It's an important document in the world of
>> SRTE, and the document goes to good lengths to describe the various
>> scenarios and combinations.
>>
>>         Ce message et ses pieces jointes peuvent contenir des
>> informations confidentielles ou privilegiees et ne doivent donc
>>         If you have received this email in error, please notify the
>> sender and delete this message and its attachments.

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 28 Mar 2021 19:24:55 -0400

All

After further review with Siva the use case is for connecting SR islands
over RSVP-TE core.

So this is for stitching SR-TE on the edge islands binding SID to core
RSVP-TE tunnel.

One major gap  of RSVP-TE is the VRF / VPN coloring capability that in
order to achieve per VRF coloring mapping of VRF to a discrete TE tunnel
requires a separate loopback and static routes to egress PE so it does not
scale.  So for as many RSVP mapped tunnels that exist you need that many
loopbacks and static routes for the next hop rewrite to the RSVP tunnel
next hop.

So this Major gap is filled with SR VRF and app flow coloring capability
that with SR-TE Policy BSID bound to candidate path can provide the
scalability per VRF coloring.

So at the edges you may have many 100s of colored RSVP tunnels but as the
core does not scale you can not provide a 1-1 mapping of SR-TE tunnel to
RSVP tunnel.  So you would have many to 1 mappings of SR-TE tunnels to
single or aggregate.

So in my mind to only way the BSID would come into play is if you could do
a 1-1 mapping of SR-TE tunnel to RSVP tunnel.  Technically that is not
possible.

For PCE to compute end to end path in this scenario does RSVP-TE require
the BSID for the stitching even if a many SR-TE colors to single RSVP-TE
tunnel mapping. I would not think so.

If we think that for PCE to build the end to end path even for the end to
end path in this scenario requires BSID binding to the RSVP-TE single path
to make contiguous end to end then I agree technically we do need to make
this inclusive of RSVP-TE.

I think we need to clear this up and if this use case is really not
feasible then we should remove any mention of BSID use with RSVP-TE tunnel.

Kind Regards

Gyan

On Sat, Mar 27, 2021 at 3:05 PM Siva Sivabalan <[email-masked]> wrote:

> Hi Gyan,
>
> BSID can be allocated for RSVP-TE as well, and yes, there are use-cases
> for that. The proposed PCEP extension is equally applicable to both SR-TE
> and RSVP-TE.
>
> Thanks,
> Siva
>
>>>     On 2021-03-18, 7:09 AM, "Pce on behalf of [email-masked]"
>>> <[email-masked] on behalf of [email-masked]> wrote:
>>>
>>>         Hi all,
>>>
>>>         pas etre diffuses, exploites ou copies sans autorisation. Si
>>> vous avez recu ce message par erreur, veuillez le signaler

*Gyan Mishra*

*M 301 502-1347*

---

From: Siva Sivabalan <[email-masked]>
Date: Sun, 28 Mar 2021 19:33:38 -0400

Hi Gyan,

This ID is all about signaling BSID for RSVP-TE tunnels and SR policies via
PCEP.

Please do not confuse signaling aspects with how BSID is used.

There is no change required in the ID.

Thanks,
Siva

On Sun, Mar 28, 2021 at 7:25 PM Gyan Mishra <[email-masked]> wrote:

>>> I see there are a lot of comments related to a mix of verbiage related
>>> to MPLS label binding and Binding label SID confusion.
>>>
>>> Few comments.
>>>
>>> So I am thinking a more appropriate name for the TLV would be
>>> “SR-TE-BSID TLV”.  Makes it clear and concise the TLV is for SR-TE.
>>>
>>> Kind Regards
>>>
>>> Gyan
>>>
>>>>         As emails may be altered, Orange is not liable for messages
>>>> that have been modified, changed or falsified.
>>>>         Thank you.
>>>>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 28 Mar 2021 19:52:56 -0400

Hi Siva

I believe  I was missing the signaling aspect for the PCE to build the
contiguous end to end LSP and that requires BSID to be signaled over
RSVP-TE which is although agnostic to data plane BSID component binding the
candidate path to the forwarding plane, is a requirement for end to end
control plane signaling for the single LSP end to end path instantiation.

The BSID signaling concept is somewhat analogous concept to LDP tunneling
over RSVP-TE tunnel stitching for an end to end LSP instantiation.

Thank you Siva for the clarification.

Gyan

On Sun, Mar 28, 2021 at 7:33 PM Siva Sivabalan <[email-masked]> wrote:

> Hi Gyan,
>
> This ID is all about signaling BSID for RSVP-TE tunnels and SR policies
> via PCEP.
>
>> So in my mind to only way the BSID would come into play is if you could
>> do a 1-1 mapping of SR-TE tunnel to RSVP tunnel.  Technically that is not
>> possible.
>>
>>>> In the abstract it states it is possible to associate a BSID with a
>>>> RSVP signaled path.
>>>>
>>>> I don’t recall any RSVP extension to support concept of BSID usage on
>>>> an active Candidate Path option ERO.  Can you refer me to the RFC that
>>>> states how BSID is used with RSVP TE.
>>>>
>>>>> Thanks for clarifying the text in the document. Diff content looks
>>>>> good to me, much clearer. Consider my comments resolved.
>>>>>
>>>>> Thanks!
>>>>> Andrew
>>>>>
>>>>>     I find the "governed by PCC local policy" a bit too vague and
>>>>> could lead to implementation interop differences. Assuming a PCInitiated
>>>>> LSP that been established with a BSID: If the PCE wants to withdraw the
>>>>> binding SID , I interpret the document as the PCE would send a PCUpdate
>>>>> without the TLV, but the behaviour is now up to PCC as per that text. if
>>>>> the PCC local policy/implementation is to do nothing, how can the PCE
>>>>> explicitly force-remove the BSID with a PCUpdate? In a similar manner, If
>>>>> the PCE does not want to change the value but PCC local policy is to treat
>>>>> missing TLV as remove, then PCE should always send the TLV in every
>>>>> PCUpdate (which I'm okay with) which is not stated, otherwise the local
>>>>> policy/implementation may interpret it as a removal compared to an
>>>>> implementation which may interpret it as being okay to not send the TLV on
>>>>> every PCUpdate since there was "no change".
>>>>>
>>>>>         a l'expediteur et le detruire ainsi que les pieces jointes.
>>>>> Les messages electroniques etant susceptibles d'alteration,

*Gyan Mishra*

*M 301 502-1347*

---

From: "Mike Koldychev (mkoldych)" <[email-masked]>
Date: Mon, 29 Mar 2021 08:50:30 +0000

Hi,

I think that BSID is a concept that applies equally well to RSVP-TE and SR-TE. There are many use-cases for RSVP tunnels having a BSID and we definitely DO NOT want to limit it to just SR-TE.

Thanks,
Mike.

From: Pce <[email-masked]> On Behalf Of Gyan Mishra
Sent: Sunday, March 28, 2021 7:53 PM
To: Siva Sivabalan <[email-masked]>
Cc: [email-masked]; [email-masked]; Stone, Andrew (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi Siva

I believe  I was missing the signaling aspect for the PCE to build the contiguous end to end LSP and that requires BSID to be signaled over RSVP-TE which is although agnostic to data plane BSID component binding the candidate path to the forwarding plane, is a requirement for end to end control plane signaling for the single LSP end to end path instantiation.

The BSID signaling concept is somewhat analogous concept to LDP tunneling over RSVP-TE tunnel stitching for an end to end LSP instantiation.

Gyan

On Sun, Mar 28, 2021 at 7:33 PM Siva Sivabalan <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

This ID is all about signaling BSID for RSVP-TE tunnels and SR policies via PCEP.

Thanks,
Siva

On Sun, Mar 28, 2021 at 7:25 PM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

All

After further review with Siva the use case is for connecting SR islands over RSVP-TE core.

So this is for stitching SR-TE on the edge islands binding SID to core RSVP-TE tunnel.

One major gap  of RSVP-TE is the VRF / VPN coloring capability that in order to achieve per VRF coloring mapping of VRF to a discrete TE tunnel requires a separate loopback and static routes to egress PE so it does not scale.  So for as many RSVP mapped tunnels that exist you need that many loopbacks and static routes for the next hop rewrite to the RSVP tunnel next hop.

So this Major gap is filled with SR VRF and app flow coloring capability that with SR-TE Policy BSID bound to candidate path can provide the scalability per VRF coloring.

So at the edges you may have many 100s of colored RSVP tunnels but as the core does not scale you can not provide a 1-1 mapping of SR-TE tunnel to RSVP tunnel.  So you would have many to 1 mappings of SR-TE tunnels to single or aggregate.

So in my mind to only way the BSID would come into play is if you could do a 1-1 mapping of SR-TE tunnel to RSVP tunnel.  Technically that is not possible.

For PCE to compute end to end path in this scenario does RSVP-TE require the BSID for the stitching even if a many SR-TE colors to single RSVP-TE tunnel mapping. I would not think so.

If we think that for PCE to build the end to end path even for the end to end path in this scenario requires BSID binding to the RSVP-TE single path to make contiguous end to end then I agree technically we do need to make this inclusive of RSVP-TE.

I think we need to clear this up and if this use case is really not feasible then we should remove any mention of BSID use with RSVP-TE tunnel.

Kind Regards

Gyan

On Sat, Mar 27, 2021 at 3:05 PM Siva Sivabalan <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

BSID can be allocated for RSVP-TE as well, and yes, there are use-cases for that. The proposed PCEP extension is equally applicable to both SR-TE and RSVP-TE.

Thanks,
Siva

On Sat, Mar 27, 2021 at 1:40 PM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

I see there are a lot of comments related to a mix of verbiage related to MPLS label binding and Binding label SID confusion.

Few comments.

In the abstract it states it is possible to associate a BSID with a RSVP signaled path.

I don’t recall any RSVP extension to support concept of BSID usage on an active Candidate Path option ERO.  Can you refer me to the RFC that states how BSID is used with RSVP TE.

s/TE/s/SR as TE nomenclature refers to RSVP-TE and does add confusion where SR is SR.  When mentioned traffic engineered path please spell out or say SR path for clarity.

The word “binding” is very confusing as it’s used interchangeably with label binding and binding SID.

So I am thinking a more appropriate name for the TLV would be “SR-TE-BSID TLV”.  Makes it clear and concise the TLV is for SR-TE.

Kind Regards

Gyan

On Fri, Mar 26, 2021 at 9:45 PM Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks again for your help!

Cheng

-----Original Message-----
From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, March 27, 2021 2:42 AM
To: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi Cheng,

Thanks!
Andrew

On 2021-03-25, 10:49 PM, "Pce on behalf of Chengli (Cheng Li)" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Hi Andrew,

    Respect,
    Cheng

    -----Original Message-----
    From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:[email-masked]<mailto:[email-masked]>]
    Sent: Saturday, March 20, 2021 4:21 AM
    To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
    Cc: [email-masked]<mailto:[email-masked]>
    Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

    Hi all,

    Thanks!

    Thanks!
    Andrew

    On 2021-03-18, 7:09 AM, "Pce on behalf of [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

        Hi all,

        Thanks,

        Dhruv & Julien

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

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

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 29 Mar 2021 09:50:39 -0400

Hi Mike

Is the usage for BSID only for control plane signaling as I described it.

What other use cases exist and maybe we should add to the draft.

Thanks

Gyan

On Mon, Mar 29, 2021 at 4:50 AM Mike Koldychev (mkoldych) <
[email-masked]> wrote:

> Hi,
>
>
>
> I think that BSID is a concept that applies equally well to RSVP-TE and
> SR-TE. There are many use-cases for RSVP tunnels having a BSID and we
> definitely DO NOT want to limit it to just SR-TE.
>
>
>
> Thanks,
>
> Mike.
>
>
>
> *From:* Pce <[email-masked]> *On Behalf Of * Gyan Mishra
> *Sent:* Sunday, March 28, 2021 7:53 PM
> *To:* Siva Sivabalan <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; Stone,
> Andrew (Nokia - CA/Ottawa) <[email-masked]>
> *Subject:* Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07
> (and Code Point Allocation)
>
>
>
>
>
> Hi Siva
>
>
>
> *Network Solutions Architect *
>
> *Network Solutions Architect *
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 29 Mar 2021 19:35:37 +0530

Hi Gyan,

As a WG member...

IMHO PCE I-D should not go into the data-plane handling of BSID, that is
SPRING/MPLS/6MAN perview.

Thanks!
Dhruv

On Mon, Mar 29, 2021 at 7:21 PM Gyan Mishra <[email-masked]> wrote:

>> *Subject:* Re: [Pce] WG Last Call for

---

From: Siva Sivabalan <[email-masked]>
Date: Mon, 29 Mar 2021 10:07:26 -0400

+1

On Mon, Mar 29, 2021 at 10:06 AM Dhruv Dhody <[email-masked]> wrote:

>>> The BSID signaling concept is somewhat analogous concept to LDP
>>> tunneling over RSVP-TE tunnel stitching for an end to end LSP instantiation.
>>>
>>>
>>>
>>> So at the edges you may have many 100s of colored RSVP tunnels but as
>>> the core does not scale you can not provide a 1-1 mapping of SR-TE tunnel
>>> to RSVP tunnel.  So you would have many to 1 mappings of SR-TE tunnels to
>>> single or aggregate.
>>>
>>>
>>>
>>> If we think that for PCE to build the end to end path even for the end
>>> to end path in this scenario requires BSID binding to the RSVP-TE single
>>> path to make contiguous end to end then I agree technically we do need to
>>> make this inclusive of RSVP-TE.
>>>
>>>
>>>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 29 Mar 2021 10:20:20 -0400

Understood.  I-D covers only BSID control plane handling for both RSVP-TE
and SR-TE

However, for RSVP-TE their is only a control plane component where SR both
control and data plane of which the SR-MPLS and SRv6 data plane is handled
in SPRING/MPLS/6MAN.

Gyan

On Mon, Mar 29, 2021 at 10:07 AM Siva Sivabalan <[email-masked]> wrote:

>>>> So this Major gap is filled with SR VRF and app flow coloring
>>>> capability that with SR-TE Policy BSID bound to candidate path can provide
>>>> the scalability per VRF coloring.
>>>>
>>>>
>>>>
>>>> For PCE to compute end to end path in this scenario does RSVP-TE
>>>> require the BSID for the stitching even if a many SR-TE colors to single
>>>> RSVP-TE tunnel mapping. I would not think so.
>>>>
>>>>
>>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: <[email-masked]>
Date: Tue, 30 Mar 2021 12:47:05 +0200

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.

Cheers,

Julien

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

---

From: <[email-masked]>
Date: Wed, 31 Mar 2021 20:00:22 +0200

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 ?

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

Olivier Dugeon

fixe : +33 2 96 07 28 80

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 1 Apr 2021 00:08:48 +0530

Hi Olivier,

> 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

> > 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.
> > [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?
> > 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:
> >
> handling the protocol entities defined by the code points (henceforth called
> 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
> >
> >
> >
> 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,
> information that may be protected by law;