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

From: Rakesh Gandhi <[email-masked]>
Date: Sat, 1 Feb 2020 11:46:18 -0500

Thanks Andrew.
Adding Adrian who had a similar comment in a different thread.

Hi Dhruv, Cheng,

For all other association types (VN, Policy, diversity, etc.), we do not
have different types defined for RSVP and SR. If we use the same
association type and limit the LSPs to be the same type (PST) in the
bidirectional LSP, then may be implementation can handle the logic for the
PST type accordingly? As IANA allocation has not been done, current
implementation can be adjusted?

Thanks,
Rakesh

On Thu, Jan 23, 2020 at 9:40 PM Stone, Andrew (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> Hi Rakesh,
>
> Thanks for the reply and input. I initially had the same thought as well:
> "just migrate both sides at the same time". Only concern is of course some
> migration strategies choose to migrate regionally or node-by-node, rather
> than tunnel pairs. In this case, definitely will have to do both sides at
> the same time. It may not actually be that troublesome, since I'm not an
> operator just going by what I've heard from colleagues and theorizing the
> situation.
>
> Cheers
> Andrew
>
> ------------------------------
> *From:* Rakesh Gandhi <[email-masked]>
> *Sent:* Thursday, January 23, 2020 11:12 AM
> *To:* Stone, Andrew (Nokia - CA/Ottawa) <[email-masked]>
> *Cc:* Dhruv Dhody <[email-masked]>; [email-masked] <[email-masked]>
> *Subject:* Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?
>
> Hi Andrew,
>
> Many thanks for your review comments. Please see below with <RG2>..
>
> On Wed, Jan 22, 2020 at 10:57 PM Stone, Andrew (Nokia - CA/Ottawa) <
> [email-masked]> wrote:
>
> Hi Dhruv,
>
> Thanks again for the speedy reply. Comments below under <andrew2>
>
> Cheers
> Andrew
>
> On 2020-01-22, 8:01 AM, "Dhruv Dhody" <[email-masked]> wrote:
>
>     Hi Andrew,
>
>     On Wed, Jan 22, 2020 at 12:06 AM Stone, Andrew (Nokia - CA/Ottawa)
>     <[email-masked]> 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>
>
>
>
> <RG2> I would think that the migration would happen for the whole
> bidirectional LSP on both endpoints at the same time. This is because, all
> nodes would have migrated to be SR aware in order for the forward path to
> be SR path (I am thinking co-routed). In addition, the complexity to
> associate the SR and RSVP paths into a bidirectional path is not small,
> given that SR path ingress node would know the reverse path via signaling
> whereas RSVP path ingress node would know via PCEP.  Which also means, one
> would need to upgrade the RSVP ingress node anyways to learn the reverse SR
> path. Traffic steering and other functions for the RSVP path and SR path in
> the reverse direction (and vice versa) may bring additional work.
>
> <RG2> Having said that, the same association group type can be used for SR
> and RSVP paths (e.g. both are the same PST) in theory, but given the
> implementation status in the draft, I will let respective co-authors
> comment.
>
>
>
>
>
>     > 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
>
>
> <RG2> Looks good to me. Thanks for the text.
> <RG2> Many thanks Dhruv for the inputs.
>
> Thanks,
> Rakesh
>
>
>
>
> </end andrew2>
>
>
>
>
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 2 Feb 2020 20:52:38 -0000

Thanks Rakesh,

It seems to me that associating an SR path in one direction with an RSVP-TE path in the other direction is *possible* but seems unlikely in the extreme. I would not want to take an action that made it impossible to add this feature should someone come up with a pressing desire, but it looks like an odd thing to specifically engineer into the solution at this stage.

Of course, a way to test this would be to send an email to SPRING and TEAS to ask this specific question. After all, the purpose of PCE is to serve as a tool to facilitate what the people in those two WGs are trying to do.

The two questions raised in the earlier threads are related to this, but do not quite cancel each other out.

1.	Do we need two different association types, one for RSVP-TE and one for SR?
2.	Is it an error if there is an attempt to associate an LSP with an SR path?

Best,

Adrian

From: Rakesh Gandhi <[email-masked]> 
Sent: 01 February 2020 16:46
To: Stone, Andrew (Nokia - CA/Ottawa) <[email-masked]>
Cc: Dhruv Dhody <[email-masked]>; [email-masked]; Farrel Adrian <[email-masked]>
Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

Thanks Andrew.

Hi Dhruv, Cheng,

For all other association types (VN, Policy, diversity, etc.), we do not have different types defined for RSVP and SR. If we use the same association type and limit the LSPs to be the same type (PST) in the bidirectional LSP, then may be implementation can handle the logic for the PST type accordingly? As IANA allocation has not been done, current implementation can be adjusted?

Thanks,

Rakesh

On Thu, Jan 23, 2020 at 9:40 PM Stone, Andrew (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]> > wrote:

Hi Rakesh,

Thanks for the reply and input. I initially had the same thought as well: "just migrate both sides at the same time". Only concern is of course some migration strategies choose to migrate regionally or node-by-node, rather than tunnel pairs. In this case, definitely will have to do both sides at the same time. It may not actually be that troublesome, since I'm not an operator just going by what I've heard from colleagues and theorizing the situation.

Cheers

Andrew

  _____  

From: Rakesh Gandhi <[email-masked] <mailto:[email-masked]> >
Sent: Thursday, January 23, 2020 11:12 AM
To: Stone, Andrew (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]> >
Cc: Dhruv Dhody <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? 

Hi Andrew,

On Wed, Jan 22, 2020 at 10:57 PM Stone, Andrew (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]> > wrote:

Hi Dhruv,

Cheers
Andrew

On 2020-01-22, 8:01 AM, "Dhruv Dhody" <[email-masked] <mailto:[email-masked]> > wrote:

    Hi Andrew,

    On Wed, Jan 22, 2020 at 12:06 AM Stone, Andrew (Nokia - CA/Ottawa)
    <[email-masked] <mailto:[email-masked]> > wrote:
    > 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.
    >

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

<RG2> I would think that the migration would happen for the whole bidirectional LSP on both endpoints at the same time. This is because, all nodes would have migrated to be SR aware in order for the forward path to be SR path (I am thinking co-routed). In addition, the complexity to associate the SR and RSVP paths into a bidirectional path is not small, given that SR path ingress node would know the reverse path via signaling whereas RSVP path ingress node would know via PCEP.  Which also means, one would need to upgrade the RSVP ingress node anyways to learn the reverse SR path. Traffic steering and other functions for the RSVP path and SR path in the reverse direction (and vice versa) may bring additional work.

<RG2> Having said that, the same association group type can be used for SR and RSVP paths (e.g. both are the same PST) in theory, but given the implementation status in the draft, I will let respective co-authors comment.

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

<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

===new proposal

   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 

   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

Thanks,

Rakesh

</end andrew2>

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 3 Feb 2020 11:26:07 +0530

Hi Adrian, Rakesh,

Valid questions. I was also wondering if it would help if we
generalise the association-type names -

such as -

Double-sided Bidirectional LSP Association Group with LSP signalling
(used for RSVP-TE)
Double-sided Bidirectional LSP Association Group without LSP signaling
(used by SR, PCECC, some future mix case etc)

or

Double-sided Bidirectional LSP Association Group (used for RSVP-TE)
Double-sided Bidirectional LSP Association Group with reverse
direction LSP encoded in PCEP (used by SR, PCECC, some future mix
cases etc)

I feel this would help those early implementer that wanted to decide
the processing based on configured association type rather than the
PST of the first LSP that joins the association, and fits well with
different bi-directional association types based on the expected
processing at PCE, as well do not lead to too many association types.

Thoughts?

Dhruv

On Mon, Feb 3, 2020 at 2:22 AM Adrian Farrel <[email-masked]> wrote:
> Do we need two different association types, one for RSVP-TE and one for SR?
> Is it an error if there is an attempt to associate an LSP with an SR path?
>
>
>
> Best,
>
> Adrian
>
>
>
> On Thu, Jan 23, 2020 at 9:40 PM Stone, Andrew (Nokia - CA/Ottawa) <[email-masked]> wrote:
>
> Hi Rakesh,
>
>
>
> ________________________________
>
> Cc: Dhruv Dhody <[email-masked]>; [email-masked] <[email-masked]>
> On Wed, Jan 22, 2020 at 10:57 PM Stone, Andrew (Nokia - CA/Ottawa) <[email-masked]> wrote:
>
> Hi Dhruv,
>

---

From: <[email-masked]>
Date: Wed, 5 Feb 2020 22:08:57 +0100

Hi all,

This I-D has enough support to be adopted.

Before we proceed, we'd like to see an update addressing at least the
issue about the number of names on the front page. Authors, please
submit a -07 version accordingly, so that we can move the draft forward.

Thanks,

Dhruv & Julien

On 17/01/2020 11:12, [email-masked] wrote:
> Hi all,
>
> It is time to share your thoughts about draft-li-pce-sr-bidir-path-06.
> Do you believe the I-D is a right foundation for a PCE WG item? Please
> use the PCE mailing list to express your comments, support or
> disagreement, including applicable rationale, especially for the latter.
>
> Thanks,
>
> Dhruv & Julien
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Rakesh Gandhi <[email-masked]>
Date: Thu, 6 Feb 2020 12:40:44 -0500

Hi Julien,
We have posted a revised draft 07 to address the comment on the author
list.
We plan to address the remained comments in the adopted revision.
Please let us know if ok to post draft-ietf-pce-sr-bidir-path-00.

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-li-pce-sr-bidir-path-07
https://datatracker.ietf.org/doc/html/draft-li-pce-sr-bidir-path-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-li-pce-sr-bidir-path-07

Thanks,
Rakesh (behalf of authors)

---

From: <[email-masked]>
Date: Fri, 7 Feb 2020 09:58:46 +0100

Hi Rakesh,

Thanks for the quick update. We're ready to adopt this version. You may
now submit it as draft-ietf-pce-sr-bidir-path-00.

Cheers,

Dhruv & Julien

On 06/02/2020 18:40, Rakesh Gandhi wrote:
> On Wed, Feb 5, 2020 at 4:09 PM <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     On 17/01/2020 11:12, [email-masked]
>     <mailto:[email-masked]> wrote:
>     > Hi all,
>     >
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

_________________________________________________________________________________________________________________________

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.

---

From: Rakesh Gandhi <[email-masked]>
Date: Fri, 7 Feb 2020 09:27:26 -0500

Hi Julien, WG,
We have posted the draft with new name:

https://tools.ietf.org/html/draft-ietf-pce-sr-bidir-path-00
https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path-00

Thanks,

On Fri, Feb 7, 2020 at 3:58 AM <[email-masked]> wrote:

> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;