Dear authors / PCE WG
I have reviewed this document as its shepherd and have the following comments.
Overall, I found this a very well written document, and most of the comments
are minor. My apologies for delivering these after the working group last call
has concluded.
Please let me know what you think.
Best regards
Jon
Section 1
"network layering can be support" -> "network layering can be supported"
Section 2
"a hybrid nodes" -> "a hybrid node"
"In this case, PCE needs to be" -> "In this case, a PCE needs to be"
Section 3.1
This text:
o However, when the I flag is set (one), the M flag is clear (zero),
and the T flag is clear (zero), since triggered signaling is not
allowed, virtual TE links must not be used in path computation.
I don't think I agree with this interpretation. The virtual TE links have been
set up ahead of time, and are already in the link state database for the client
layer, I believe? If so, using them for a client layer path should not require
any additional triggered signalling within the server layer. My understanding
of this combination of bits is that the computed path may use virtual TE links
in the client layer, but may not use loose hops across the server layer, or
specify nodes/links in the server layer as explicit hops. Please tell me if I
am misunderstanding this.
I think we should strengthen the requirements of the following text:
Reserved bits of the INTER-LAYER object SHOULD be transmitted as zero
and SHOULD be ignored on receipt. A PCE that forwards a path
computation request to other PCEs SHOULD preserve the settings of
reserved bits in the PCReq messages it sends and in the PCRep
messages it forwards to PCCs.
as follows:
Reserved bits of the INTER-LAYER object sent between a PCC and
PCE in the same domain MUST be transmitted as zero
and SHOULD be ignored on receipt. A PCE that forwards a path
computation request to other PCEs MUST preserve the settings of
reserved bits in the PCReq messages it sends and in the PCRep
messages it forwards to PCCs.
Otherwise, an implementation that chooses to ignore the SHOULDs could break any
new features that want to use the reserved bits.
A few typos in 3.1:
"and also in PCRpt, PCUpd, and PCInitiate message" -> "and also in PCRpt,
PCUpd, and PCInitiate messages"
"When M flag is set (zero)" -> "When M flag is clear (zero)"
"or stitched (xref target="RFC5150" /> LSPs" : stray text "xref target" -
bugged XML?
Section 3.3
"without INTER-LAYER Object" -> "without an INTER-LAYER Object"
Section 3.5
This text:
Optional TLVs: Optional TLVs may be included within the object to
specify more specific server layer path information (e.g., traffic
parameters).
I think it would be better to say
Optional TLVs: Optional TLVs MAY be included within the object to
specify more specific server layer path information (e.g., traffic
parameters). Such TLVs will be defined by other documents.
Section 4.1
Please expand the acronym VNTM on first use.
Please include reference to RFC 5541 when discussing the OF object.
Section 4.2
"PCE MAY specify" -> "The PCE MAY specify"
"the requested PCE replies a PCRep message" -> "the requested PCE sends a PCRep
message"
Section 4.3
"message objects define in this" -> "message objects defined in this"
Section 5
Minor typo in the RBNF:
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
That should be [<svec-list>].
Section 7.2
The description of the T bit should probably be "Triggered Signalling Allowed"
to be consistent with the other two (which are named according to their role on
the PCReq).
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
