Hi all,
I read the version -19 and I support the publication of this document.
Thanks for the work from authors. I think it is a long and well-written
document with detailed descriptions of the PCEP extensions and operations.
The PCEP extensions are useful for many multipath use cases such as
load-balancing paths, backup paths, reverse paths and composite paths.
I have two suggestions for your considerations.
1, Since the note in section 4.1.1 is described as "Note that F-flag and C-flag
can be set independently, i.e., F-flag can be set, but C-flag not set, etc." I
think that the MULTIPATH-FORWARD-CLASS is not only used in the concept of the
Composite Candidate Path. They may be decoupled. So I suggest that 3.6
Composite Candidate Path and 3.6.1 Per-Flow Candidate Path can be defined
separately such as 3.7 Per-Flow Candidate Path or 3.7 MULTIPATH-FORWARD-CLASS
TLV.
2, In section 4.2 Path ID, it said "The Path ID uniquely identifies a Path
within the context of an LSP. Note that when the LSP is an SR Policy Candidate
Path, the Paths within that LSP are the Segment Lists." When the Path ID is
used in Composite Candidate Path, the Path ID can also identify the SR policy.
So I am not sure if I understand correctly that the Path ID can be used to
identify an LSP, an SR Policy Candidate Path, a segment list or an SR policy.
It would be better to clarify the definition of the Path ID. Thanks!
Best Regards,
Quan
<This message starts a WG Last Call for:
<draft-ietf-pce-multipath-19
<This Working Group Last Call ends on 2026-02-24
<Abstract:
< Certain traffic engineering path computation problems require
< solutions that consist of multiple traffic paths that together form a
< solution. However, current PCEP extensions can only return a single
< traffic path, which cannot meet the requirements. This document
< defines mechanisms to encode multiple paths for a single set of
< objectives and constraints. This allows encoding of multiple Segment
< Lists per Candidate Path within a Segment Routing Policy. The new
< < Path Computation Element Communication Protocol (PCEP) mechanisms are
< designed to be generic, which allows for future re-use outside of SR
< < Policy. The new PCEP mechanisms are applicable to both stateless and
< stateful PCEP. Additionally, this document updates RFC 8231 and RFC
< 8281 to allow encoding of multiple Segment Lists in PCEP.
<Please indicate your support or concern for this draft on the mailing list. If
you are opposed to the progression of the draft to RFC, please <articulate your
concern. If you support it, please indicate that you have read the latest
version and that it is ready for publication in your <opinion. As always,
review comments and nits are most welcome.
<A general reminder to the WG to be more vocal during the last-call/adoption.
<Thanks,
<Dhruv & Julien
<The IETF datatracker status page for this Internet-Draft
is:https://datatracker.ietf.org/doc/draft-ietf-pce-multipath/There is also an
HTML version <available
at:https://www.ietf.org/archive/id/draft-ietf-pce-multipath-19.htmlA diff from
the previous version is available
at:https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-multipath-19
_______________________________________________
Pce mailing list -- [email protected]
To unsubscribe send an email to [email protected]
