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

["Pengshuping (Peng Shuping)" <[e-mail]>]

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:[e-mail]]
> Sent: Wednesday, January 18, 2023 4:20 AM
> To: [e-mail]
> Cc: [e-mail];
> [e-mail]
> 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 <[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-contr
> oller-srv6/
> 
>