Hi Dhruv Thanks – I have addressed this case in the latest version.
Jon From: [email protected] [mailto:[email protected]] On Behalf Of Dhruv Dhody Sent: 04 March 2018 05:41 To: [email protected] Cc: Julien Meuric <[email protected]>; [email protected]; Dhruv Dhody <[email protected]> Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11 Hi, As I was updating the PCEP-SRv6 document [1], I noticed that the behavior for 'the unknown ST (SID Type)' is not defined in the SR-ERO/SR-RRO. Could the authors take this into consideration while they make an update. Also an IANA code point sub registry needs to be setup in this document for the ST Type, so that future extensions (like SRv6) can define new ST types. Thanks! Dhruv [1] https://datatracker.ietf.org/doc/draft-negi-pce-segment-routing-ipv6/ On Tue, Jan 30, 2018 at 2:49 PM, Dhruv Dhody <[email protected]<mailto:[email protected]>> wrote: Hi, I had reviewed and given comments on the I-D in the past, which the authors had addressed. I found these additional nits/suggestions. Apologies for being late by a day. Suggestions ----------- Section 1 (1) Though it is true that a child PCE act as a PCC towards the parent PCE, I feel it is not wise to say the opposite, that is a PCC is acting as a PCE in this context. I see no advantage to bring up the H-PCE in this context. I suggest we remove it. A PCE, or a PCC operating as a PCE (in hierarchical PCE environment), computes paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on various constraints and optimization criteria. (2) Since this document is related to MPLS data plane only, it would be nice to include a pointer to the SRv6 work in PCEP for the benefit of the readers. (3) Regarding first mention of PST OLD: This specification relies on the procedures specified in [I- D.ietf-pce-lsp-setup-type]. NEW: This specification relies on the procedures specified in [I- D.ietf-pce-lsp-setup-type] for the path setup type for SR. Section 3 (4) Regarding this text - SR-TE LSPs computed by a PCE can be represented in one of the following forms: o An ordered set of IP address(es) representing network nodes/links: In this case, the PCC needs to convert the IP address(es) into the corresponding MPLS labels by consulting its Traffic Engineering Database (TED). o An ordered set of SID(s). o An ordered set of both MPLS label(s) and IP address(es): In this case, the PCC needs to convert the IP address(es) into the corresponding SID(s) by consulting its TED. Each SR-ERO object can include both SID and NAI (IP address); this case is different from the case 3 above, I suggest if some text can be added to make things clearer. Section 5.1.1 (5) Why SHOULD in this text? A PCEP speaker SHOULD indicate its support of the function described in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object with this new PST included in the PST list. Section 6 (6) Regarding, A PCEP speaker that does not support the SR PCEP capability cannot recognize the SR-ERO or SR-RRO subobjects. As such, it MUST send a PCEP error with Error-Type = 4 (Not supported object) and Error-Value = 2 (Not supported object Type) as per [RFC5440]. RFC 5440 did not state the behavior for unknown sub-object. My suggestion would be - A PCEP speaker that does not support the SR PCEP capability and thus cannot recognize the SR-ERO or SR-RRO subobjects, it will respond according to the rules for a malformed object as per [RFC5440]. Section 7 (7) Suggest to make Manageability Consideration section as per RFC 6123 (8) PCEP-Yang should be mentioned in section 7.2 Section 8 (9) Suggest we expand the security consideration section a bit based on recent DISCUSSes. Nits ---- Section 5.3.1 s/MUST not/MUST NOT/ Section 5.3.3 (2) OLD: A PCEP speaker that does not recognize the SR-ERO subobject in PCRep, PCInitiate, PCUpd or PCRpt messages MUST reject the entire PCEP message and MUST send a PCErr message with Error-Type=3 ("Unknown Object") and Error-Value=2 ("Unrecognized object Type") or Error- Type=4 ("Not supported object") and Error-Value=2 ("Not supported object Type"), defined in [RFC5440]. NEW: A PCEP speaker that does not recognize or support the SR-ERO subobject in PCRep, PCInitiate, PCUpd or PCRpt messages MUST reject the entire PCEP message and MUST send a PCErr message with Error-Type=3 ("Unknown Object") and Error-Value=2 ("Unrecognized object Type") or Error- Type=4 ("Not supported object") and Error- Value=2 ("Not supported object Type"), defined in [RFC5440]. (3) I agree with Adrian that the ".. not identical" needs to change. Since you mean all subobject in ERO must be of SR-ERO type, we should just call it that! (also applicable for SR-RRO). Thanks! Dhruv > -----Original Message----- > From: Pce [mailto:[email protected]<mailto:[email protected]>] On > Behalf Of Julien Meuric > Sent: 15 January 2018 15:08 > To: [email protected]<mailto:[email protected]> > Subject: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11 > > Dear PCE WG, > > Best wishes for this new year, full of interoperable specifications. Let > us begin by resuming our work in progress. > > This message starts a 2-week WG last call for draft-ietf-pce-segment- > routing-11. Please send your feedback on the I-D to the PCE mailing list > by Monday January 29. > > Regards, > > Jon & Julien > > _______________________________________________ > Pce mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
