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

Hi Olivier,

On Wed, Mar 31, 2021 at 11:30 PM <olivier.dugeon@orange.com> wrote:

> Hi Cheng, Aijun,
>
> I think that the 'R' bit to clearly indicate that BSID is removed
> is mandatory. In fact, in case of multiple BSID, it will become clearly
> a nightmare from an implementation point of view to manage the removal.
>
> Let me take a simple example:
>
> Assume a PCE would setup some BSID into a PCC. It first send a PcInitiate
> message with an empty TE-PATH-BINDING TLV to request a BSID. PCC send a
> PcRpt
> message with a BSID=1 (simple value). Then, the PCE would a second BSID.
> So, it
> sends a PcUpdate message with a TE-PATH-BINDING TLV and the first BSID=1
> and a
> second empty TE-PATH-BINDING TLV to get the second one. PCC sends back a
> PcRpt
> message with the 2 TE-PATH-BINDING BSID=1 and BSDI=2. We repeat the last
> operation
> to collect a third BSID=3. Now the PCE would remove the BSID=2. It must
> send a
> PcUpdate message with TE-PATH-BINDING BSID=1, TE-PATH-BINDING BSID=3 and an
> empty TE-PATH-BINDING.
>
> So, how the PCC could determine that this last emptyTE-PATH-BINDING
> corresponds
> to a deletion and not a creation ?
>
>
Looking at the working copy[1]/diff[2] that Cheng posted, the empty
TE-PATH-BINDING TLV is used to request allocation only (and not to withdraw
old values). So in the example above to remove BSID=2, the PCUpd message
with TE-PATH-BINDING BSID=1 & TE-PATH-BINDING BSID=3 are sent.

Adrian provided some cleaner text that has been incorporated for this now.
Does the updated text resolve this?

Thanks!
Dhruv (as a WG participant)

[1]
https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-08.txt
[2]
https://tools.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-pce-binding-label-sid-07.txt&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-08.txt

> There is a large risk of ambiguity in particular if the PCE does not send
> the TE-PATH-BINDING TLVs in the right order, if PCE and PCC become
> de-synchronize
> on the number of BSID ...
>
> Thus, I think that a 'R' bit for deletion is mandatory.
>
> Regards
>
> Olivier
>
> Le 26/03/2021 à 03:46, Chengli (Cheng Li) a écrit :
> > Hi Aijun,
> >
> > Many thanks for your comments! Please see my reply inline. The diff is
> attached.
> >
> > Respect,
> > Cheng
> >
> >
> >
> > -----Original Message-----
> > From: Aijun Wang [mailto:wangaijun@tsinghua.org.cn]
> > Sent: Monday, March 22, 2021 11:57 AM
> > To: julien.meuric@orange.com; pce@ietf.org
> > Cc: draft-ietf-pce-binding-label-sid@ietf.org
> > Subject: RE: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07
> (and Code Point Allocation)
> >
> > Hi,
> >
> > 1. The concept of PCC requests the allocating of BSID for a LSP is
> clear, but the scenario that PCE allocate the BSID is not convincible.
> >   PCE can request the PCC to allocate the BSID for one LSP. It should
> not allocate the value directly.
> >
> >
> > [Cheng]Section 8 is optionally used when PCE is in control of label
> space (PCECC) and would not be used for vanilla stateful PCE.
> >
> > 2. What's the reason to include the BT=3, that is "SRv6 Endpoint
> Behavior and SID Structure"? It is one general information and not close
> connection to the normal usage of BSID.
> > [Cheng] This is an alignment with other SIDs. In order to support
> backward compatibility, we want to remain BT2, and introduce a new BT for
> support SID structure. It can be used for future use case.
> >
> >
> > 3. Will it be more clear to define one new bit(R bit) within the Flag
> field of "TE-PATH-BINDING TLV" to indicate clearly the remove of BSID
> allocation to a LSP? Instead of the implicit method that depending on the
> presence of TE-PATH-BINDING TLV as described in current draft?
> > [Cheng] It is possible. But there are existing implementations that
> would get impacted.
> >
> >
> > 4. For BT=0, the length is set to 7. How to skip the padding trailing
> zeros to a 4-octet boundary when parsing?
> > [Cheng] We have updated the description of BT=0 as per Adrian's comment.
> Length=7 and handling of padding is as per RFC5440:
> >
> >    The Length field defines the length of the value portion in bytes.
> >    The TLV is padded to 4-bytes alignment; padding is not included in
> >    the Length field (so a 3-byte value would have a length of 3, but the
> >    total size of the TLV would be 8 bytes).
> >
> > Best Regards
> >
> > Aijun Wang
> > China Telecom
> >
> > -----Original Message-----
> > From: pce-bounces@ietf.org <pce-bounces@ietf.org> On Behalf Of
> julien.meuric@orange.com
> > Sent: Thursday, March 18, 2021 7:09 PM
> > To: pce@ietf.org
> > Cc: draft-ietf-pce-binding-label-sid@ietf.org
> > Subject: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and
> Code Point Allocation)
> >
> > Hi all,
> >
> > This message initiates a 2-week PCE WG Last Call for
> draft-ietf-pce-binding-label-sid-07. Please review and share your feedback,
> whatever it is, using the PCE mailing list. This WGLC will end on Thursday
> April 1st (no kidding).
> >
> >
> > Moreover, we have received a request from the authors for a code point
> allocation to support interoperability testing.
> >
> > RFC 7120 requires to meet the following criteria to proceed:
> >
> > b. The format, semantics, processing, and other rules related to
> handling the protocol entities defined by the code points (henceforth called
> > "specifications") must be adequately described in an Internet-Draft.
> > c. The specifications of these code points must be stable; i.e., if
> there is a change, implementations based on the earlier and later
> specifications must be seamlessly interoperable.
> >
> > If anyone believes that the draft does not meet these criteria, or
> believes that early allocation is not appropriate for any other reason,
> please send an email to the PCE mailing list explaining why. If the chairs
> hear no objections by Thursday, March 25th, we will kick off the "early"
> allocation request.
> >
> > Thanks,
> >
> > Dhruv & Julien
> >
> >
> >
> ____________________________________________________________________________
> > _____________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message par
> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> >
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> > Thank you.
> >
> > _______________________________________________
> > Pce mailing list
> > Pce@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce
> >
> >
> > _______________________________________________
> > Pce mailing list
> > Pce@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce
> --
> Orange logo <http://www.orange.com>
>
>
>
> Olivier Dugeon
> Orange Expert, Future Networks
> Open Source Referent
> Orange/IMT/OLN/WTC/IEE/iTeQ
>
>
>
> fixe : +33 2 96 07 28 80
> mobile : +33 6 82 90 37 85
> olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>
>
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>