[Pce] Re: Éric Vyncke's Discuss on draft-ietf-pce-sr-bidir-path-22: (with DISCUSS and COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Rakesh,

Thanks for your message: we are progressing to a solution. For the contentious section 2, what about something like

"This document extends the following term defined in [RFC3031]: Label Switched Path (LSP), while the base PCEP ... signaling protocol. As specified in the Terminology Section of [RFC9603], ... Setup Type." ?

Of course, with RFC 3031 & 9603 being normative.

Regards,

-éric

From: Rakesh Gandhi (rgandhi) <[e-mail]>
Date: Saturday, 28 February 2026 at 05:22
To: Eric Vyncke (evyncke) <[e-mail]>, The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-pce-sr-bidir-path-22: (with DISCUSS and COMMENT)

Thank you, Eric for the review comments.

Please see replies inline with <RG>...

Also, attaching the work in progress diff file and TXT file.

From: Éric Vyncke via Datatracker <[e-mail]>
Date: Friday, February 27, 2026 at 10:12 AM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Éric Vyncke's Discuss on draft-ietf-pce-sr-bidir-path-22: (with DISCUSS and COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-pce-sr-bidir-path-22: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-sr-bidir-path/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke INT AD comments for draft-ietf-pce-sr-bidir-path-22
CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points (easy to address), some
non-blocking COMMENT points/nits (replies would be appreciated even if only for
my own education).

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of
https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by
a tool to create github issues.

## DISCUSS (blocking)

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise.

### Section 2

I am afraid that a document cannot define "LSP" as in RFC 3031 (which is only
about MPLS), then add a note explaining that SRv6 SID list can be shoehorned in
the MPLS LSP. Consider rewriting this section without mentionning RFC 3031. If
reference to RFC 3031 is kept, then it must be normative and not informative as
in the current I-D.

<RG> RFC 3031 introduces the term LSP as:

      label switched path       The path through one or more LSRs at one
                                level of the hierarchy followed by a
                                packets in a particular FEC.

<RG> I think it is good to keep this reference. We have changed RFC 3031 to normative.
<RG> The SRv6 LSP text is copy and paste from RFC 9603. I think it’s good to keep it as it is in that RFC.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

## COMMENTS (non-blocking)

### Abstract

Strongly suggest rewriting the abstract as it is mostly unreadable (is the
first paragraph required?).

<RG> Ok, how about the following:

   Segment Routing (SR) steers packets through a network using the IPv6
   or MPLS data planes via source routing.  Stateful Path Computation
   Element Communication Protocol (PCEP) extensions are defined for SR
   Traffic Engineering (TE) LSPs.

   PCEP supports grouping two RSVP-TE-signaled, unidirectional MPLS-TE
   Label-Switched Paths (LSPs) with one in each direction in a network
   into an associated bidirectional LSP.  This document extends PCEP
   support to group two unidirectional SR LSPs into an associated
   bidirectional SR LSP.  The mechanisms defined in this document apply
   to both stateless and stateful PCEs for PCE-initiated and PCC-
   initiated LSPs.


Thanks,
Rakesh


## NITS (very cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate
SVG graphics. It is worth a try especially if the I-D uses the Kramdown file
format ;-)