Hi Adrian, all, We have updated this draft and hoped that we have resolved your comments. Thank you! https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-pce-controller-srv6-01
Here is the diff for your convenience. https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-pcep-extension-pce-controller-srv6-00&url2=draft-ietf-pce-pcep-extension-pce-controller-srv6-01&difftype=--html Best Regards, Shuping > -----Original Message----- > From: Adrian Farrel [mailto:adr...@olddog.co.uk] > Sent: Wednesday, January 18, 2023 4:20 AM > To: pce@ietf.org > Cc: julien.meu...@orange.com; > draft-dhody-pce-pcep-extension-pce-controller-s...@ietf.org > Subject: Re: [Pce] WG Adoption of > draft-dhody-pce-pcep-extension-pce-controller-srv6 > > 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 <pce-boun...@ietf.org> On Behalf Of julien.meu...@orange.com > Sent: 16 January 2023 18:00 > To: pce@ietf.org > 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-contr > oller-srv6/ > > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce