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, julien.meu...@orange.com a écrit : > 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 > -- 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.dug...@orange.com <mailto:olivier.dug...@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