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

From: <[email-masked]>
Date: Fri, 17 Jan 2020 11:12:33 +0100

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

---

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Sun, 19 Jan 2020 22:57:45 +0000

Hi PCE WG and Authors,

It's possible some of these items have been discussed prior to me following the WG, so apologies in advance if that's the case. Some questions/comments regarding the document:

  *   Agree, PCEP definition/support for SR Bi-dir associated LSPs is needed feature set and work to be covered by the WG
  *   For bidirectional associating two LSPs, does PCC/PCE need an additional way to distinguish whether it's an SR or an RSVP bidirectional association? Would that not be implicit based on the path setup type of the LSPs which have been associated together? In other words, do we actually need double-sided bidirectional SR association group object defined? draft-li-pce-sr-bidir-path-06 seems to imply the behavior is basically the same as MPLS-TE (minus the RSVP signalling of course) and the object encoding is the same, so does yet-another object need to be defined? From a PCEP message encoding p.o.v within an association object structure, are 2 SR LSPs that different than associating 2 RSVP LSPs?
  *   While I can appreciate the need for textual clarity, and perhaps I'm missing something, but for some reason I find sections 1, 3, and 4 quite verbose to essentially say at it's core: "use the objects defined in draft-ietf-pce-association-bidir, except use this new value type double-sided-bidirectional-sr instead. You can also use path segment".
  *   In Section 5 I would prefer the document would say "there are use cases which require the PCC to be aware of the reverse direction SR path. A PCE MAY inform the reverse SR Paths to the ingress PCCs and vice versa in order to provide functionality for those use cases". Associating two LSPs together and never informing them of each others reverse path is a valid, simple use case. Therefore having PCC informed of the reverse path to achieve further use cases is truly "OPTIONAL" in my opinion.
  *   Related to previous point, my preference would be for references to pce-sr-path-segment be considered as a MAY, as there isn't a need for path-segment in a basic case of associating bi-directional LSPs for PCE to manage/compute bi-directional paths for.
  *   Section 5 I think needs a bit more discussion:
     *   I agree the PCC should not instantiate the reverse path, but it's not stated how to make this decision. I assume this is easy enough to decide with the reverse (r) bit in the association object? Might be worth mention.
     *   indicates PCE needs to allocate a PLSP-ID for the reverse path to tell the ingress PCC, due to potential PLSPID space collision. RFC 8231 & RFC8281 has PCC owning the PLSP-ID. At first I was confused, then remembered about PCE Controlled ID space draft. I suppose this text is a carry over from path segment integration, but li-pce-controlled-id-space is not referenced directly, more transitively via path-segment which is only SHOULD as an inclusion. My question is, is there actually a need to use PCE Controlled ID space to achieve notifying the PCC about the reverse path? Would the indication of "PCE-init + R bit" be enough to let PCC generate the PLSP-ID and report it back, while also not instantiating the path?
     *   Possibly depending on the outcome of previous comment, I would recommend the diagrams in 5.1 and 5.2 include example PLSP-IDs.

In general this document appears to be a good base to work from to achieve bi-dir sr association.

Support adoption.

Thanks
Andrew

________________________________
From: Pce <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Friday, January 17, 2020 5:12 AM
To: [email-masked] <[email-masked]>
Subject: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

Hi all,

Thanks,

Dhruv & Julien

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 20 Jan 2020 09:49:41 -0500

Hi Andrew,

Thank you for your review comments. Please see some comments inline with
<RG>.

On Sun, Jan 19, 2020 at 5:57 PM Stone, Andrew (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> Hi PCE WG and Authors,
>
> It's possible some of these items have been discussed prior to me
> following the WG, so apologies in advance if that's the case. Some
> questions/comments regarding the document:
>
>    - Agree, PCEP definition/support for SR Bi-dir associated LSPs is
>    needed feature set and work to be covered by the WG
>
> <RG> Great, thanks.

>
>    - For bidirectional associating two LSPs, does PCC/PCE need an
>    additional way to distinguish whether it's an SR or an RSVP bidirectional
>    association? Would that not be implicit based on the path setup type of the
>    LSPs which have been associated together? In other words, do we actually
>    need double-sided bidirectional SR association group object defined?
>    draft-li-pce-sr-bidir-path-06 seems to imply the behavior is basically the
>    same as MPLS-TE (minus the RSVP signalling of course) and the object
>    encoding is the same, so does yet-another object need to be defined? From a
>    PCEP message encoding p.o.v within an association object structure, are 2
>    SR LSPs that different than associating 2 RSVP LSPs?
>
>
<RG> Main difference is that in case of RSVP-TE, the egress node learns the
reverse LSP via RSVP signaling whereas in case of SR, the egress node
learns the reverse LSP via PCE.

>
>    - While I can appreciate the need for textual clarity, and perhaps I'm
>    missing something, but for some reason I find sections 1, 3, and 4 quite
>    verbose to essentially say at it's core: "use the objects defined in
>    draft-ietf-pce-association-bidir, except use this new value type
>    double-sided-bidirectional-sr instead. You can also use path segment".
>
>
>    - In Section 5 I would prefer the document would say* "there are use
>    ca**ses which require the PCC to be aware of the reverse direction SR
>    path. A PCE MAY inform the reverse SR Paths to the ingress PCCs and vice
>    versa in order to provide functionality for those use cases"*.
>    Associating two LSPs together and never informing them of each others
>    reverse path is a valid, simple use case. Therefore having PCC informed of
>    the reverse path to achieve further use cases is truly "OPTIONAL" in my
>    opinion.
>
>
<RG> Agree.

>    - Related to previous point, my preference would be for references to
>    pce-sr-path-segment be considered as a MAY, as there isn't a need for
>    path-segment in a basic case of associating bi-directional LSPs for PCE to
>    manage/compute bi-directional paths for.
>
>
<RG> Agree.

>
>    - Section 5 I think needs a bit more discussion:
>       - I agree the PCC should not instantiate the reverse path, but it's
>       not stated how to make this decision. I assume this is easy enough to
>       decide with the reverse (r) bit in the association object? Might be worth
>       mention.
>
>
<RG> Ok.

>
>    - indicates PCE needs to allocate a PLSP-ID for the reverse path to
>       tell the ingress PCC, due to potential PLSPID space collision. RFC 8231 &
>       RFC8281 has PCC owning the PLSP-ID. At first I was confused, then
>       remembered about PCE Controlled ID space draft. I suppose this text is a
>       carry over from path segment integration, but li-pce-controlled-id-space is
>       not referenced directly, more transitively via path-segment which is only
>       SHOULD as an inclusion. My question is, is there actually a need to use PCE
>       Controlled ID space to achieve notifying the PCC about the reverse path?
>       Would the indication of "PCE-init + R bit" be enough to let PCC generate
>       the PLSP-ID and report it back, while also not instantiating the path?
>       - Possibly depending on the outcome of previous comment, I would
>       recommend the diagrams in 5.1 and 5.2 include example PLSP-IDs.
>
>
<RG> I will let Dhruv and other co-authors comment on this.

Thanks for your support.

Thanks,
Rakesh

>    -
> ------------------------------
> *From:* Pce <[email-masked]> on behalf of [email-masked] <
> [email-masked]>
> *Sent:* Friday, January 17, 2020 5:12 AM
> *To:* [email-masked] <[email-masked]>
> *Subject:* [Pce] Adoption of draft-li-pce-sr-bidir-path-06?
>
> Hi all,
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

---

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 20 Jan 2020 15:41:51 +0000

Hi Rakesh,

Thanks for the speedy reply. One follow up comment below.

Cheers
Andrew

From: Rakesh Gandhi <[email-masked]>
Date: Monday, January 20, 2020 at 9:49 AM
To: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

Hi Andrew,

Thank you for your review comments. Please see some comments inline with <RG>.

On Sun, Jan 19, 2020 at 5:57 PM Stone, Andrew (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
Hi PCE WG and Authors,

<RG> Main difference is that in case of RSVP-TE, the egress node learns the reverse LSP via RSVP signaling whereas in case of SR, the egress node learns the reverse LSP via PCE.

<Andrew> Yes, I realize that, however the association structure is about informing PCE to associate two LSPs together, is it not? It’s not related to how 2 LSPs learn each opposite reverse path. To be specific, my comment is regarding section 3.1. To instruct PCE “make these 2 bidirectional” is a separate task than how the LSPs learn of each other’s reverse LSP and path in my opinion. So to inform PCE “these 2 LSPs are bidirectional, make them so” is the same instruction irrelevant of how each LSP learns of each others path. For SR, yes there is the added process where PCE may need to tell the PCC the opposite path, but that decision is a behaviour post-association being provided, which can be determined as necessary by the LSP path setup type of the associated LSPs. So if the goal of to instruct PCE “these 2 LSPs are bidirectional”, that instruction is common between LSPs whether they are RSVP or SR. Essentially defining 'Double-sided Bidirectional SR Path Association Group' is not required (unless there’s something else in that object we foresee being specific to SR in the future).

<RG> Agree.

<RG> Agree.

<RG> Ok.

Thanks for your support.

Thanks,
Rakesh

     *

Support adoption.

Thanks
Andrew

________________________________
From: Pce <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Friday, January 17, 2020 5:12 AM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

Hi all,

Thanks,

Dhruv & Julien

_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 20 Jan 2020 12:48:18 -0500

Hi Andrew,
Thank you for your comment. Yes, the point of using PST (SR/RSVP) was
discussed during the early stage of the draft and was converged to define a
new association type, specifically due to the extra requirements related to
the reverse LSP for SR. I will let other co-authors comments further.

Thanks,
Rakesh

On Mon, Jan 20, 2020 at 10:41 AM Stone, Andrew (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> *From: *Rakesh Gandhi <[email-masked]>
> *Date: *Monday, January 20, 2020 at 9:49 AM
> *To: *"Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?
>
>
>
> Hi Andrew,
>
>
>
> <RG> Main difference is that in case of RSVP-TE, the egress node learns
> the reverse LSP via RSVP signaling whereas in case of SR, the egress node
> <Andrew> Yes, I realize that, however the association structure is about
> informing PCE to associate two LSPs together, is it not? It’s not related
> to how 2 LSPs learn each opposite reverse path. To be specific, my comment
> is regarding section 3.1. To instruct PCE “make these 2 bidirectional” is a
> separate task than how the LSPs learn of each other’s reverse LSP and path
> in my opinion. So to inform PCE “these 2 LSPs are bidirectional, make them
> so” is the same instruction irrelevant of how each LSP learns of each
> others path. For SR, yes there is the added process where PCE may need to
> tell the PCC the opposite path, but that decision is a behaviour
> post-association being provided, which can be determined as necessary by
> the LSP path setup type of the associated LSPs. So if the goal of to
> instruct PCE “these 2 LSPs are bidirectional”, that instruction is common
> between LSPs whether they are RSVP or SR. Essentially defining
> 'Double-sided Bidirectional SR Path Association Group' is not required
> (unless there’s something else in that object we foresee being specific to
> SR in the future).
>
>
>
>
>
>
>    cases which require the PCC to be aware of the reverse direction SR path. A
>    PCE MAY inform the reverse SR Paths to the ingress PCCs and vice versa in
>    order to provide functionality for those use cases"*. Associating two
>    LSPs together and never informing them of each others reverse path is a
>    valid, simple use case. Therefore having PCC informed of the reverse path
>    to achieve further use cases is truly "OPTIONAL" in my opinion.
>
>
>
> <RG> Agree.
>
>
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 20 Jan 2020 19:32:26 -0000

Hey Julien, WG,

I have reviewed draft-li-pce-sr-bidir-path as part of the adoption poll
and I have a few comments below.

Overall, this seems like a simple combination of two existing functions:
- associated bidirectional
- SR
So it should be straightforward and the function is clearly needed, and
the working group should adopt it if there is enough support.

Thanks,
Adrian

===

Please (please, please) could author teams sort out their front page
author list before requesting WG adoption. If the authors don't reduce
themselves to a maximum of five, the chairs will have to do it, and I
don't think anyone wants that!

---

Abstract

   This document defines PCEP extensions for grouping two reverse
   unidirectional SR Paths into an Associated Bidirectional SR Path when
   using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as
   well as when using a Stateless PCE.

I don't think it is "two reverse unidirectional SR paths". One of them
is normal and the other is reverse. So how about...

   This document defines PCEP extensions for grouping two unidirectional
   SR Paths (one in each direction in the network) into a single
   Associated Bidirectional SR Path.  The mechanisms defined in this
   document can also be applied using a Stateful PCE for both PCE-
   Initiated and PCC-Initiated LSPs, as well as when using a Stateless
   PCE.

---

Section 1

s/SR supports to steer packets/SR supports steering packets/

---

Section 1

   Currently, SR networks only support unidirectional paths.  However,
   bidirectional SR Paths are required in some networks, for example, in
   mobile backhaul transport networks.  The requirement of bidirectional
   SR Path is specified in [I-D.ietf-spring-mpls-path-segment].

I suggest...

   SR is specified for unidirectional paths.  However, some applications
   require bidirectional paths in SR networks, for example, in mobile
   backhaul transport networks.  The requirement for bidirectional
   SR Paths is specified in [I-D.ietf-spring-mpls-path-segment].

---

Section 1

OLD
   [I-D.ietf-pce-association-bidir] defines PCEP extensions for grouping
   two reverse unidirectional MPLS TE LSPs into an Associated
   Bidirectional LSP when using a Stateful PCE for both PCE-Initiated
   and PCC-Initiated LSPs as well as when using a Stateless PCE.
NEW
   [I-D.ietf-pce-association-bidir] defines PCEP extensions for grouping
   two unidirectional MPLS TE LSPs into an Associated Bidirectional LSP 
   when using a Stateful PCE for both PCE-Initiated and PCC-Initiated
   LSPs as well as when using a Stateless PCE.
END

---

3.1 and 7.1

Why do you need a new Association Type? 
If draft-ietf-pce-association-bidir was changes as:
OLD
   Value Name                                            Reference
   ---------------------------------------------------------------------
   TBD1 Single-sided Bidirectional LSP Association Group [This document]
   TBD2 Double-sided Bidirectional LSP Association Group [This document]
NEW
   Value Name                                            Reference
   ---------------------------------------------------------------------
   TBD1 Single-sided Bidirectional Association Group [This document]
   TBD2 Double-sided Bidirectional Association Group [This document]
END
...then you could use the second of these for your use case. The type of
path being associated would/should be the same for both paths in the
association (but maybe there would be a future case with an LSP in one
direction and an SR path in the other direction? but see section 5.3)
and the type of path known from the PCEP message.

---

Section 5

   The PCE SHOULD inform the reverse SR Paths to
   the ingress PCCs and vice versa.

Under what circumstance MAY the PCE choose to not do this?

---

5.3 and 7.2

Depending on how you handle the point for 3.1, you may need to fine tune
this error code.  One way approach might be to make a change to 
draft-ietf-pce-association-bidir as:
OLD 
   Error Type  Description                              Reference
   -------------------------------------------------------------------
    29         Association Error

               Error value: TBD2                        This document
               Bidirectional LSP Association -
               Path Setup Type Mismatch
NEW
   Error Type  Description                              Reference
   -------------------------------------------------------------------
    29         Association Error

               Error value: TBD2                        This document
               Bidirectional Association -
               Path Setup Type Mismatch
END

---

Having made the suggestions for 3.1 and 5.3, I wonder how much is 
different from draft-ietf-pce-association-bidir. Is this just a small
explanation of the use of that draft in the SR network

---

You should explicitly reference the figures (by name) from the text.

---

Thanks for Section 6. I find it really helpful.

---

-----Original Message-----
From: Pce <[email-masked]> On Behalf Of [email-masked]
Sent: 17 January 2020 10:13
To: [email-masked]
Subject: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

Hi all,

Thanks,

Dhruv & Julien

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 21 Jan 2020 15:31:09 +0530

Hi Andrew,

Speaking as a WG contributor and snipping to -

> For bidirectional associating two LSPs, does PCC/PCE need an additional way to distinguish whether it's an SR or an RSVP bidirectional association? Would that not be implicit based on the path setup type of the LSPs which have been associated together? In other words, do we actually need double-sided bidirectional SR association group object defined? draft-li-pce-sr-bidir-path-06 seems to imply the behavior is basically the same as MPLS-TE (minus the RSVP signalling of course) and the object encoding is the same, so does yet-another object need to be defined? From a PCEP message encoding p.o.v within an association object structure, are 2 SR LSPs that different than associating 2 RSVP LSPs?
>
>
>

I remember this being discussed in the mailing list, and the decision
was that there are enough of a difference between the processing of
double-sided bi-directional for RSVP-TE and SR paths to have different
association types for the ease of implementation. Implementers were
also worried that the PST of the first LSP that joins the associations
would decide the next action and could lead to issues. In case one
tried to add SR and RSVP-TE path in one association, where one peer
may add SR first and reject RSVP-TE and other pcep peer may add
RSVP-TE first and reject SR and there could be some mismatch. This was
done mainly for the ease of implementations.

Thanks!
Dhruv

---

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 21 Jan 2020 18:36:06 +0000

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. 

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. 

Thanks again,
Andrew

On 2020-01-21, 5:01 AM, "Dhruv Dhody" <[email-masked]> wrote:

    Hi Andrew,

    
    
    Thanks!
    Dhruv

---

From: Rakesh Gandhi <[email-masked]>
Date: Tue, 21 Jan 2020 19:30:40 -0500

Hi WG,

Support (as a co-author) to make this a WG document.

Thanks,
Rakesh

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 22 Jan 2020 02:31:56 +0000

Hi PCE,

support as a co-author. 

Thanks,
Cheng

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, January 17, 2020 6:13 PM
To: [email-masked]
Subject: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

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

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 22 Jan 2020 18:31:16 +0530

Hi Andrew,

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

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.

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

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.

Thanks!
Dhruv

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 23 Jan 2020 11:53:40 +0800

Hi WG,

   Support the adption.
   I have read the draft, it is ready to be a WG document.
   The extensions to PCEP were clear and the procedures to setup bidirectional SR-LSP were given too.
   One comment: If we need SR-LSP redundancy, how should we do at the bidirectional SR-LSP scenario?

Best Regards,
Huanan

From: [email-masked]
Date: 2020-01-17 18:12
To: [email-masked]
Subject: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?
Hi all,

Thanks,
 
Dhruv & Julien

---

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 23 Jan 2020 03:57:23 +0000

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,

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

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

---

From: Rakesh Gandhi <[email-masked]>
Date: Thu, 23 Jan 2020 10:36:55 -0500

Hi Huanan,
Thank you for your support.

Do you mean how bidirectional SR would work with path protection as in:
https://tools.ietf.org/html/draft-ietf-pce-stateful-path-protection-11

If yes, both are complementary. We can add text to indicate so.

Thanks,
Rakesh

On Wed, Jan 22, 2020 at 10:53 PM [email-masked] <
[email-masked]> wrote:

> *From:* [email-masked]
> *Date:* 2020-01-17 18:12
> *To:* [email-masked]

---

From: Rakesh Gandhi <[email-masked]>
Date: Thu, 23 Jan 2020 11:12:37 -0500

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:

>     > 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.
>     >
>
> 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.
>     >
>
> 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
<RG2> Looks good to me. Thanks for the text.
<RG2> Many thanks Dhruv for the inputs.

Thanks,
Rakesh

---

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 24 Jan 2020 02:40:44 +0000

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,

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,

<Andrew2>

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

<Andrew2>

===current

===new proposal

=====end new proposal

Thanks,
Rakesh

</end andrew2>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 23 Jan 2020 20:14:09 -0800

Dear All,
I've read the draft and support its adoption.

Regards,
Greg

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 24 Jan 2020 06:35:23 +0000

Hi WG,

I (as a coauthor) support the adoption of this document.

Best regards,
Jie

发件人：julien.meuric <[email-masked]>
收件人：pce <[email-masked]>
时 间：2020-01-17 18:13:12
主 题：[Pce] Adoption of draft-li-pce-sr-bidir-path-06?

Hi all,

Thanks,

Dhruv & Julien

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 24 Jan 2020 12:44:52 +0000

Support!

Thanks

Regards … Zafar

From: Pce <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Organization: Orange
Date: Friday, January 17, 2020 at 5:13 AM
To: "[email-masked]" <[email-masked]>
Subject: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

Hi all,

Thanks,

Dhruv & Julien

---

From: Lizhenbin <[email-masked]>
Date: Sun, 26 Jan 2020 09:40:30 +0000

Hi WG,

I support the adoption of this document.

Best regards,
Zhenbin (Robin)

--------------------------------------------------
李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: [email-masked]<mailto:[email-masked]>

发件人：Zafar Ali (zali) <[email-masked]>
收件人：julien.meuric <[email-masked]>;pce <[email-masked]>
时 间：2020-01-24 20:45:25
主 题：Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

Support!

Thanks

Regards … Zafar

Hi all,

Thanks,

Dhruv & Julien

---

From: Zhuangshunwan <[email-masked]>
Date: Sun, 26 Jan 2020 12:11:56 +0000

Support.

Thanks
Shunwan

From: Pce <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Organization: Orange
Date: Friday, January 17, 2020 at 5:13 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

Hi all,

Thanks,

Dhruv & Julien

---

From: Zhenghaomian <[email-masked]>
Date: Sun, 26 Jan 2020 14:17:09 +0000

Yes/Support. 

Best wishes,
Haomian

-----邮件原件-----
发件人: Pce [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2020年1月17日 18:13
收件人: [email-masked]
主题: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

Hi all,

Thanks,

Dhruv & Julien

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 30 Jan 2020 11:32:51 +0800

support!

Best Regards,
Zhenqiang Li

[email-masked]

 
Thanks,
 
Dhruv & Julien

---

From: Rakesh Gandhi <[email-masked]>
Date: Fri, 31 Jan 2020 16:05:53 -0500

Thank you Adrian for the review comments. Please see inline with <RG>...

>    Initiated and PCC-Initiated LSPs, as well as when using a Stateless

<RG> Ack.

> s/SR supports to steer packets/SR supports steering packets/

<RG> Ack.

>    SR Paths is specified in [I-D.ietf-spring-mpls-path-segment].

<RG. Ack.

>    LSPs as well as when using a Stateless PCE.

<RG> Ack.

> ....then you could use the second of these for your use case. The type of

<RG> There was an email discussion on this topic on the list. Please see
following threads. Please let us know if you have additional thoughts on
this.

https://mailarchive.ietf.org/arch/msg/pce/LnTR_PfHlNG4BRyKLvkQuGdAmbU

https://mailarchive.ietf.org/arch/msg/pce/APYWjr7vzXsHkD9Sj3G6Y_cNYwg

> Under what circumstance MAY the PCE choose to not do this?

<RG> OAM use-cases require reverse path but simple traffic steering
use-case on co-routed path on two ingress nodes may not need to know the
reverse SR path. Not sure if this SHOULD be MUST.

>    Error Type  Description                              Reference

<RG> Ok, will change the names in draft-ietf-pce-association-bidir.

> You should explicitly reference the figures (by name) from the text.
<RG> Ack.

> Thanks for Section 6. I find it really helpful.

<RG> Thanks Adrian.

Regards,
Rakesh