Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

["Stone, Andrew (Nokia - CA/Ottawa)" <[e-mail]>]

Hi Dhruv,

Thanks again for the speedy reply. Comments below under <andrew2>

Cheers
Andrew

On 2020-01-22, 8:01 AM, "Dhruv Dhody" <[e-mail]> wrote:

    Hi Andrew,
    
    On Wed, Jan 22, 2020 at 12:06 AM Stone, Andrew (Nokia - CA/Ottawa)
    <[e-mail]> wrote:
    >
    > Hi Dhruv,
    >
    > Thanks for the reply and feedback.
    >
    > Could an implementation of PCE not simply just return error during that situation? In diversity if too many LSPs grouped together and PCE computationally can't support it, it returns a PCERR. So I would reason that if bidirectionally associated and notify PCCs is necessary, but was configured between SR and RSVP, that's also an error due to the (current) unsupported feature set. I see this as trying to protect against day-0 misconfig by changing the wire encoding within the protocol (which I'm not necessarily against..). While I have doubt if it's a valid use case or requirement in a production deployment, and it may have been acknowledged before, but this essentially blocks associating SR LSP with RSVP LSP bidirectionally for PCE to compute.
    >
    > Since the overall workflow doesn't change by this new type def, and if SR<->RSVP associated is not reasonable requirement, and If consensus has already been reached on this, and implementation already exist, I'm okay with parking this topic.
    >
    
    The SR draft does expect all LSPs to be SR for the new association
    type and thus easier to handle. If you use a common association type,
    the behavior would be dependent on the PST for the first LSP that is
    added to the association. We could end up in a situation where Peer 1
    would add LSP 1 (SR) first and reject LSP 2 (RSVP-TE) and peer 2 would
    add LSP 2 (RSVP-TE) first and reject LSP 1 (SR). Also there might be a
    use for this mixed cases in future, which would require different
    processing to be defined.


<Andrew2> 

I will ponder on this some more. I'm undecided yet if the reasons to protect config/behaviour mismatch, outweigh just having one type encoding and defining the individual behaviours separately, which could also be up to the local policy defined by the PCE implementation. 

It could be possible that a network has nodes currently running RSVP, with plans to migrate to SR-TE which could take a very long time due to the size of the network. The software running on the nodes may be upgraded, of which those PCCs may have an implementation of these bidirectional drafts, but have still not yet migrated to SR-TE. An operator may wish to leverage PCE feature sets on newer created services sooner than later (for example, bidirectional capability) so they begin using bidirectional RSVP to have symmetric paths for SLA reasons and aid in avoiding manual traffic engineering. Over time, as the network is migrated to SR-TE tunnels you have some nodes using SR-TE tunnels and the reverse nodes still operating with RSVP. From an operator p.o.v the bidirectional notification behaviour here wouldn't matter, they just want the LSPs to take the same resources symmetrically. The feature set on PCE, as per the current draft wording and types will be broken. 

</end andrew2>
    

    > Still hoping for feedback regarding my comments on section 5. I see that as being more significant, since it influences the workflow and at the moment I don't see the dependency on draft-li-pce-controlled-id-space as necessary to achieve notifying PCCs of reverse paths.
    >
    
    And I was hoping that authors would take a bite :)
    From what I understood PLSP-ID remains a PCC allocated ID. The point
    that section 5 is making is that the same LSP would be identified by
    two PLSP-IDs, one allocated by Ingress and another by Egress PCCs.
    There is no proposal for PCE-controlled PLSP-ID. So PCE-init + R bit
    is enough  (as you state) and I am in full agreement with you that
    figures with PLSP-ID could be useful.
    



<Andrew2> 

Thanks for the comments and agreement. draft-li-pce-sr-bidir-path-06 section 5.1, says "PCE needs to allocate a PLSP-ID". Perhaps it was just a typo and should have said PCC. 

===current
   Since the PLSP-ID space is independent at each PCC, the PLSP-ID
   allocated by the egress PCC can not be used for the LSP at the
   ingress PCC (PLSP-ID conflict may occur).  Hence, the PCE needs to
   allocate a PLSP-ID for LSP2 from the ingress PCC's PLSP-ID space ,
   say 101.  Similarly for LSP1, it has PLSP-ID 100 at the ingress, and
   may have say PLSP-ID 201 at the egress node.
=====end current


May I propose the following text  (or something like it) instead:

 
===new proposal

   Since the PLSP-ID space is independent at each PCC, the PLSP-ID
   allocated by the egress PCC cannot be used for the LSP at the
   ingress PCC (PLSP-ID conflict may occur). As per normal PCE-INIT 
   operations, PCC assigns the PLSP-IDs for local LSPs.
   Hence, when the PCE notifies an ingress PCC of the reverse egress LSP, it
   does so using PCE-INIT operations and sets PLSP-ID to zero and sets the R bit in the association 
   object to indicate that this PCE-INIT LSP is a reverse LSP. The PCC 
   upon receiving the PCE-INIT MUST locally assign a PLSP-ID and it MUST
   issue a PCREPORT to PCE for this LSP containing the new PLSP-ID. This 
   LSP MUST NOT be instantiated on the PCC. 

   For example, ingress PCC1 way may report to PCE an LSP with 
   PLSP-ID 100. Egress PCC2 may report to PCE an LSP with PLSP-ID 200. 
   Both of these LSPs are bi-directional associated. When PCE 
   notifies PCC1 of the PCC2 LSP, it does so by sending a PCE-INIT to PCC1 with 
   PLSP-ID set to zero and R bit set. PCC1 upon reception of this generates a PLSP-ID 
   (example PLSP-ID 300) and issues a PCREPORT to PCE. 

=====end new proposal
   


</end andrew2>