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

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

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]>
Date: Thursday, 7 May 2026 at 18:42
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; pce-chairs <[e-mail]>; [e-mail] <[e-mail]>; Adrian Farrel <[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