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

["Chengli (Cheng Li)" <[e-mail]>]

Hi Olivier,

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

Respect,
Cheng


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Saturday, March 20, 2021 12:39 AM
To: [e-mail]; [e-mail]; [e-mail]
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:

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

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


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

[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.


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


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


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

[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, [e-mail] 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
> [e-mail]
> 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 : [phone]
mobile : [phone]
[e-mail] <mailto:[e-mail]>


_________________________________________________________________________________________________________________________

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.