ietf
[Top] [All Lists]

RE: [Pce] Last Call: <draft-ietf-pce-pcep-service-aware-12.txt> (Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP).) to Proposed Standard

2016-08-31 08:18:29
Nice job and very fast!

I am happy with all the changes, but one caution...

4.2.3.1 should not define legacy behavior. A legacy node will not see this
spec and cannot be influenced by what you write. So...

OLD
   If a PCE receives a PCReq message containing a BU object, and the PCE
   does not understand or support the BU object, and the P bit is clear
   in the BU object header then the PCE SHOULD simply ignore the BU
   object.

   If the PCE does not understand the BU object, and the P bit is set in
   the BU object header, then the PCE MUST send a PCErr message
   containing a PCEP-ERROR Object with Error-Type = 3 (Unknown object)
   and Error-value = 1 (Unrecognized object class) as per [RFC5440].
NEW
   The behavior of a PCE that does not understand an object that it
   receives on PCReq message is defined in [RFC5440] and depends on the
   setting of the P bit in the object header (P bit clear means ignore
   the object, P but set means return an "Unknown object" error).
END

[Dhruv] I have updated it as -
     If the BU object is unknown/unsupported, the PCE MUST follow
     procedures defined in [RFC5440]. That is, if the P bit is set, the
     PCE sends a PCErr message with error type 3 or 4 (Unknown / Not
     supported object) and error value 1 or 2 (unknown / unsupported
     object class / object type), and the related path computation
     request MUST be discarded.  If the P bit is cleared, the PCE is
     free to ignore the object.

You still have normative language in this document to describe how an
implementation that has not read this document is required to behave.  I don't
think that can work.

I suggest s/MUST/will/.

Cheers,
Adrian