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]] On Behalf Of Julien Meuric
> Sent: 15 January 2018 15:08
> To: [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]
> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
