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 <[email protected]> On Behalf Of [email protected]
Sent: 16 January 2023 18:00
To: [email protected]
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/
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
