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

["Adrian Farrel" <[e-mail]>]

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 <[e-mail]> On Behalf Of [e-mail]
Sent: 17 January 2020 10:13
To: [e-mail]
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