[Pce] Re: Handling of Backup TLV in draft-ietf-pce-multipath.

["Samuel Sidor (ssidor)" <[e-mail]>]

Thanks Dhruv, Ketan,

Hooman (and other authors of P2MP SR Policy draft) - is it possible to update draft-ietf-pce-sr-p2mp-policy based on dropped changes (see in my previous mail) from multipath draft and based on suggestion from Dhruv for IANA section?

I just posted v25 for multipath.

Thanks,
Samuel

From: Dhruv Dhody <[e-mail]>
Date: Wednesday, 13 May 2026 at 10:05
To: Ketan Talaulikar <[e-mail]>
Cc: Samuel Sidor (ssidor) <[e-mail]>; Samuel Sidor (ssidor) <ssidor=[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; pce-chairs <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Handling of Backup TLV in draft-ietf-pce-multipath.

Hi Samuel,

The IANA Considerations section in the P2MP SR Policy draft should note that early allocation for these codepoints already exists, and request that IANA update the reference from the previous draft to the P2MP draft. No re-allocation needed — just a reference update, and we can coordinate that directly with IANA.

Thanks!
Dhruv

On Tue, May 12, 2026 at 10:58 PM Ketan Talaulikar <[e-mail]<mailto:[e-mail]>> wrote:
Hi Samuel/All,

Sounds good to me.

Dhruv/Julien, please let me know once this update is posted and the WG is ready for me to proceed with IETF LC.

Thanks,
Ketan


On Mon, May 11, 2026 at 1:18 PM Samuel Sidor (ssidor) <[e-mail]<mailto:[e-mail]>> wrote:
One more minor update included to handle last remaining comment from AD review (+ Ketan) - added following statement into Introduction:

For SR Policy, support for [RFC9862] is a prerequisite for using the multipath extensions defined in this document with SR Policy Candidate Paths.

Updated version attached.

Regards,
Samuel

From: Samuel Sidor (ssidor) <ssidor=[e-mail]<mailto:[e-mail]>>
Date: Monday, 11 May 2026 at 12:28
To: Dhruv Dhody <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; pce-chairs <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [Pce] Re: Handling of Backup TLV in draft-ietf-pce-multipath.

Thanks Dhruv,

Attaching updated version of the draft with MULTIPATH-BACKUP TLV removed.

2 small points to highlight:

  *
IANA Codepoints related to backup TLV were removed from this draft - I assume that P2MP draft can request re-assignment of those to that draft. Or would it be better to still have some explicit text trying to remove original temporary allocations at first?
  *
After remove backup capability from “Multipath Capability TLV”, we ended up with unused bit position:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |             Type              |             Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Number of Multipaths      |            Flags    |C|F|O| |W|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I’m explicitly keeping positions of other capabilities in original position to maintain backward compatibility. It is following similar change done in RFC9603 ( https://www.rfc-editor.org/rfc/rfc9603.html#name-the-srv6-pce-capability-sub)

Please let me know in case of any comments. Otherwise I’ll submit updated version tomorrow.

Thanks,
Samuel

From: Dhruv Dhody <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 7 May 2026 at 18:42
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; pce-chairs <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Subject: Handling of Backup TLV in draft-ietf-pce-multipath.

Hi WG,

Following up on the discussion about handling the Backup TLV in draft-ietf-pce-multipath.

We have not seen further discussion on the list. This was discussed before, and some authors shared their reasoning for keeping it.

>From the chairs' perspective, the preferred way forward to make progress on the document is to move the handling of the Backup TLV out of this document, preferably including it in the SR Policy P2MP I-D where it is used. This could be done with an appropriate disclaimer that this TLV might also apply to P2P in the future. An alternative is to define it in a separate, independent I-D, but that would use more WG cycles than necessary.

We believe this approach allows the current document to progress without being blocked while providing a clear path for the Backup TLV work to continue. We ask the authors to please proceed along these lines.

Thanks,
Dhruv & Julien