Hi Olivier, On Wed, Mar 31, 2021 at 11:30 PM <[email protected]> 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:[email protected]] > > Sent: Monday, March 22, 2021 11:57 AM > > To: [email protected]; [email protected] > > Cc: [email protected] > > 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 protected] <[email protected]> On Behalf Of > [email protected] > > Sent: Thursday, March 18, 2021 7:09 PM > > To: [email protected] > > Cc: [email protected] > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/pce > > > > > > _______________________________________________ > > Pce mailing list > > [email protected] > > 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 protected] <mailto:[email protected]> > > > > _________________________________________________________________________________________________________________________ > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/pce >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
