Re: [Pce] WG Adoption of draft-dhody-pce-pcep-extension-pce-controller-srv6

[Adrian Farrel <[e-mail]>]

Hi,

Tl;dr  I support the adoption of this draft.

As a co-author of RFC 8283, I take an interest in this work and the
wider applicability of PCECC. I've also been interested in how SID
allocation is coordinated, and this seems like a reasonable solution.

Given that we have procedures and protocol extensions for PCECC with
SR-MPLS, it seems pragmatic to also have them for SRv6.

Some comments and nits below, none of which needs to be actioned before
adoption.

Best,
Adrian

===

Abstract

Suggest a paragraph break before "This document"

---

Abstract

You nicely introduce PCE and PCECC, but don't introduce SR. There is,
perhaps, a sentence or two in the Introduction you could borrow...


   Segment Routing (SR) technology leverages the source routing and
   tunneling paradigms.  Each path is specified as a set of "segments" 
   encoded in the header of each packet as a list of Segment Identifiers
   (SIDs).

You'd then tidy up the subsequent text since there is no need to 
expand the abbreviations twice.

---

Abstract

s/SDN and/SDN/
s/in the for /in the/

---

1.

Although PCEP is expanded in the Abstract, you need to expand it on
first use in the main body of text.

---

1.

s/introduction to SR/introduction to the SR/
a/[RFC8665] ,/[RFC8665],/

---

1.
OLD
   [RFC8283] introduces the architecture for PCE as a central controller
NEW
   [RFC8283] introduces the architecture for PCE as a central controller
   (PCECC)
END

---

1.

   It relies on a
   series of forwarding instructions being placed in the header of a
   packet.  The list of segments forming the path is called the Segment
   List and is encoded in the packet header.

You say "in the packet header" twice.

---

1.

   PCECC may further use PCEP for SR SID (Segment Identifier) allocation
   and distribution to all the SR nodes with some benefits.  

Hmmm. Not sure PCEP is use for allocation. Maybe it is open for 
interpretation, but possibly...

   The PCECC may perform centralized allocation of SR Segment 
   Identifiers (SIDs) and use PCEP to distribute them to the SR nodes.

---

1.

   [I-D.ietf-pce-pcep-extension-pce-controller-sr] specifies the
   procedures and PCEP extensions when a PCE-based controller is also
   responsible for configuring the forwarding actions on the routers
   (SR-MPLS SID distribution), in addition to computing the paths for
   packet flows in a segment routing network and telling the edge
   routers what instructions to attach to packets as they enter the
   network.  This document extends this to include SRv6 SID distribution
   as well.

Big question first. I know the history that led us to have one I-D for
SR-MPLS and one for SRv6. The question is whether we still need to have
that, or we should adopt this document and them move for a merger so 
that the is just one draft for PCECC-SR. I assume that the philosophy of
the PCEP extensions are the same, and that it is just the encoding of
SIDs that differs. (See also the end of Section 3.)

And then, a rewrite for clarity...

   A PCE-based central controller may be responsible for computing the 
   paths for packet flows in an MPLS Segment Routing (SR-MPLS) network
   and for telling the edge routers what instructions to attach to
   packets as they enter the network.  [I-D.ietf-pce-pcep-extension-pce-
   controller-sr] specifies the procedures and PCEP extensions when a
   PCE-based controller is additionally responsible for configuring the
   forwarding actions on routers in an SR-MPLS network (i.e., for SR-
   MPLS SID distribution).  This document extends those procedures to
   include SRv6 SID distribution as well.

---

2.

s/in the document/in/

---

3.

   An
   ingress node of an SR-TE path appends all outgoing packets with a
   list of MPLS labels (SIDs).

I don't think "append" is quite the right word. It has implications of
"attach to the end of". Perhaps...

   An
   ingress node of an SR-TE path includes a list of MPLS labels (SIDs)
   in all outgoing packets.

---

3.

OLD
   The SR is applied to IPv6 data plane using SRH.
NEW
   SR is applied to the IPv6 data plane using the SRH.
END

---

3.

s/paths may not follow IGP SPT/paths might not follow the IGP SPT/
s/specify the SRv6-ERO/specifies the SRv6-ERO/
s/and assume/and assuming/
s/Further Section 3/Further, Section 3/
s/describe the implications/describes the implications/

---

3.

   The operator needs to evaluate the advantages offered by PCECC
   against the operational and scalability needs of the PCECC.

Maybe add a forward pointer to Section 9.6?

---

3.

OLD
   As per [RFC8283], PCECC can allocate and provision the node/prefix/
   adjacency label (SID) via PCEP.
NEW
   As per [RFC8283], the PCECC can allocate the node/prefix/adjacency 
   label (SID) and provision them via PCEP.
END

---

4.

s/between the PCE to the PCC/between the PCE and the PCC/

---

5.2

The material in this section is all good, but I think the flow is wrong.
Perhaps...

OLD
   This document uses the same PCEP messages and its extensions which
   are described in [RFC9050] and
   [I-D.ietf-pce-pcep-extension-pce-controller-sr] for PCECC-SRv6 as
   well.

   The PCEP messages PCRpt, PCInitiate, PCUpd are used to send LSP
   Reports, LSP setup, and LSP update respectively.  The extended
   PCInitiate message described in [RFC9050] is used to download or
   clean up CCIs (a new CCI Object-Type=TBD3 for SRv6 SID).  The
   extended PCRpt message described in [RFC9050] is also used to report
   the CCIs (SRv6 SIDs) from PCC to PCE.

   [RFC9050] specify an object called CCI for the encoding of the
   central controller's instructions.
   [I-D.ietf-pce-pcep-extension-pce-controller-sr] defined a CCI object-
   type for SR-MPLS.  This document further defines a new CCI object-
   type=TBD3 for SRv6.
NEW
   The PCEP messages PCRpt, PCInitiate, and PCUpd are used to send LSP
   reports, LSP setup, and LSP update respectively.  [RFC9050] describes
   the use of the PCInitiate message with a new objects called the CCI
   for encoding the central controller instructions.
   [I-D.ietf-pce-pcep-extension-pce-controller-sr] defines a CCI object-
   type for SR-MPLS.  

   This document uses the same PCEP messages and their extensions as
   described in [RFC9050] and 
   [I-D.ietf-pce-pcep-extension-pce-controller-sr].  It extends their
   use to PCECC-SRv6.  In particular, this document defines a new CCI
   object-type for SRv6 with type=TBD3.
END

---

5.3

OLD
   A new S bit is added in the PCECC-CAPABILITY sub-TLV to indicate
   support for PCECC-SR-MPLS in
   [I-D.ietf-pce-pcep-extension-pce-controller-sr].  This document adds
   another I bit to indicate support for SR in IPv6.  A PCC MUST set the
   I bit in the PCECC-CAPABILITY sub-TLV and include the SRv6-PCE-
   CAPABILITY sub-TLV ([I-D.ietf-pce-segment-routing-ipv6]) in the OPEN
   object (inside the PATH-SETUP-TYPE-CAPABILITY TLV) to support the
   PCECC SRv6 extensions defined in this document.
NEW
   [I-D.ietf-pce-pcep-extension-pce-controller-sr] defines the S bit in
   the PCECC-CAPABILITY sub-TLV to indicate support for PCECC-SR-MPLS.
   This document defines another bit (the I bit) to indicate PCECC 
   support for SRv6.  A PCC MUST set the I bit in the PCECC-CAPABILITY
   sub-TLV and include the SRv6-PCE-CAPABILITY sub-TLV
   ([I-D.ietf-pce-segment-routing-ipv6]) in the OPEN object (inside the
   PATH-SETUP-TYPE-CAPABILITY TLV) to support the PCECC SRv6 extensions
   defined in this document.
END

---

5.3

   If the I bit is set in PCECC-CAPABILITY sub-TLV and the SRv6-PCE-
   CAPABILITY sub-TLV is not advertised, or is advertised without the I
   bit set, in the OPEN object, the receiver MUST:

   *  send a PCErr message with Error-Type=19 (Invalid Operation) and
      Error-value=TBD4 (SRv6 capability was not advertised) and

   *  terminate the session.

This is good, but I think it only applies to receivers that are aware of
the meaning of the I bit, so...

1. s/the receiver/a receiver that implements this specification/

2. You need to precede the this text with something like...

   Implementations that are not aware of the meaning of the I bit will
   ignore it per Section 7.1.1 of [RFC8090].  Implementations that are
   not aware of the SRv6-PCE-CAPABILITY sub-TLV but receive one in the
   PATH-SETUP-TYPE-CAPABILITY TLV with the PST value of 3 set (per
   [I-D.ietf-pce-segment-routing-ipv6], will respond as described in 
   Section 5 of [RFC8408].

---

5.4

s/in TED/in the Traffic Engineering Database (TED)/
s/is used to advertise/are used to advertise/

---

5.5

s/[RFC8664] specify/[RFC8664] specifies/

---

5.5 and 7.2

You mention "early allocation by IANA". This is true, but the text will
not last well, and there is some risk of it not getting updated. Since 
the allocation has been made, and since it is the responsibility of 
another document, I suggest you just drop this text.

---

5.5.1

s/This document proposes/This document describes/

---

OLD
5.5.1.1.  PCECC SRv6 Node/Prefix SID allocation
NEW
5.5.1.1.  PCECC SRv6 Node/Prefix SID Allocation
END

---

You have:

Router-ID (5.4, 5.5.1.1)
Router ID (5.4)
router ID (5.5.1.1)

Maybe need to be consistent?

---

5.5.1.1

s/and the end result is similar/and the end result are similar/

---

OLD
5.5.1.2.  PCECC SRv6 Adjacency SID allocation
NEW
5.5.1.2.  PCECC SRv6 Adjacency SID Allocation
END

---

5.5.1.3

s/remains intact till/remain intact until/

---

5.5.1.6

s/, the PCECC/. The PCECC/

---

7.1.1 and 10.1 (also draft-ietf-pce-pcep-extension-pce-controller-sr)

I notice that IANA does not track the bit letters at 
https://www.iana.org/assignments/pcep/pcep.xhtml#pcecc-capability

It may be helpful to get IANA to track the I-bit by making your new 
entry in the registry...

                  | TBD1 | SRv6 (I-bit)    | This document |


Similarly, draft-ietf-pce-pcep-extension-pce-controller-sr might use

                  | TBD1 | SR-MPLS (S-bit) | This document |

---

7.3

   If the sum of
   all four sizes advertised in the SID Structure is larger than 128
   bits, the corresponding SRv6 SID MUST be considered invalid and a
   PCErr message with Error-Type = 10 ("Reception of an invalid object")
   and Error-Value = TBD ("Invalid SRv6 SID Structure") is returned.

draft-ietf-pce-segment-routing-ipv6 has already assigned the value 37.
Further, I think you need to make it clear that the behavior you are
describing is already specified elsewhere. So...

NEW
   According to [I-D.ietf-pce-segment-routing-ipv6], if the sum of
   all four sizes advertised in the SID Structure is larger than 128
   bits, the corresponding SRv6 SID is considered invalid and a
   PCErr message with Error-Type = 10 ("Reception of an invalid object")
   and Error-Value = 37 ("Invalid SRv6 SID Structure") is returned.
END

---

8.

You reference RFC 7525, but that was obsoleted by RFC 9325.

I suspect that all you need to do is make an update to the new
reference.

---

9.5

I think I agree with what you have written, but I wonder what happens
if PCECC is used per this document at the same time that IGP-based
mechanisms are used. Is there a conflict? How is that resolved? Does
management play a part?

---

10.2

The CCI Object Type value has been assigned (see RFC 9050). You can 
replace "TBD" with "44".

---

Through-out...

It *might* be worth renumbering the TBDs to take care of the fact that
there is no TBD2.

-----Original Message-----
From: Pce <[e-mail]> On Behalf Of [e-mail]
Sent: 16 January 2023 18:00
To: [e-mail]
Subject: [Pce] WG Adoption of draft-dhody-pce-pcep-extension-pce-controller-srv6

Hi all,

This e-mail starts an adoption poll for 
draft-dhody-pce-pcep-extension-pce-controller-srv6-10 [1]. Do you 
consider this I-D is ready to become a PCE WG item?

Please respond to the PCE list, including rationale if you believe the 
WG should not adopt it.

Thanks,

Julien


[1] 
https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-extension-pce-controller-srv6/