Thank you Adrian for the review comments. Please see inline with <RG>...
On Mon, Jan 20, 2020 at 2:32 PM Adrian Farrel <[email protected]> wrote: > 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. > > --- > <RG> Ack. > Section 1 > > s/SR supports to steer packets/SR supports steering packets/ > > --- > <RG> Ack. > 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]. > > --- > <RG. Ack. > 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 > > --- > <RG> Ack. > 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. > > --- > <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 > > 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? > > --- > <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. > > 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 > > --- > <RG> Ok, will change the names in draft-ietf-pce-association-bidir. > 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. > > --- > <RG> Ack. > Thanks for Section 6. I find it really helpful. > > --- > <RG> Thanks Adrian. Regards, Rakesh > -----Original Message----- > From: Pce <[email protected]> On Behalf Of [email protected] > Sent: 17 January 2020 10:13 > To: [email protected] > 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 > > > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
