[Pce] Progressing draft-ietf-pce-vendor-constraints after WG last call

["Adrian Farrel" <[e-mail]>]

Hi WG,

Well, we (or probably me) were a bit slow in responding to WG last call
comments. Thanks for the input.

We are preparing a new revision.

Here are some notes on what is changing.

Thanks,
Adrian

---

Nits from Julien and others picked up and included.

---

There were some discussions about whether the RBNF should be "strict" and I
think this ties in with a number of existing RFCs and a long-running debate in
the working group.

Now that there is an I-D that attempts to pull together all PCEP RBNF into a
"definitive" document, I don't think it would be right to try to embed that work
in this document. 

Furthermore, asking this I-D to fix a concern about the relative object
orderings in RFC 5440, RFC 5541, and RFC 6006 would be unreasonable.

Similarly, i don't think it falls to this I-d to define the placement of the BNC
or UNREACH-DESTINATION objects in a PCReq.

---

We have clarified the distinction in error processing between not supporting the
Vendor Information object, and not recognising the enterprise number. the text
in Section 2 now reads...

   A PCE that receives a PCReq message containing a Vendor Information
   object MUST act according to the P flag in the object header.  That
   is, if the P flag is set, the object will be treated as mandatory
   and the request will either be processed using the contents of the
   object, or the request will be rejected as defined in [RFC5440] (see
   also Section 2.1).  If the P flag is clear then, as defined in 
   [RFC5440], the object may be used by the PCE or may be ignored.  The
   PCC sets the P flag according to how it wishes the request to be
   processed.

   The PCE determines how to interpret the information in the Vendor
   Information object by examining the Enterprise Number it contains. 
   An implementation that supports the Vendor Information object, but 
   receives one carrying an Enterprise number that it does not support
   MUST act according to the P flag in the object.  That is, if the P
   flag is set, the PCE MUST reject the PCReq as defined in [RFC5440] by
   sending an Error message with Error-Type="Not supported Object" along 
   with the corresponding Vendor Information object.

...while 2.1 is unaltered.

---

Ramon suggested

> * <request> ::= I would suggest moving the vendor-info-list after 
> endpoints (for both p2p and p2mp) My personal preference would
> be after metric list and objective function. endpoint-rro-pair-list at 
> least includes one mandatory ENDPOINTS object, making the
> mandatory RP and ENDPOINTS objects appear first.

This looks good, but there is a need to distinguish between vendor info that
belongs to the <request> and vendor info that belongs to the
<end-point-rro-pair-list>. So it must appear before the first
<end-point-rro-pair-list> if it applies to the whole <request>. Hence, no
change.

[I consider it a bug in RFC 6006 that the same doesn't apply to <BANDWIDTH> and
really it would be nice to put <end-point-rro-pair-list> last in <request>.]

---

There was some push to also show RBNF for the PCRep message. Much though this
goes against the grain for me (I really think that you should all have to
implement RFC3209 a few times before complaining about PCEP ;-) and I can't
actually think of why you would put Vendor info in a PCRep (but early on someone
in the WG insisted) we have added the following:

   Thus, the PCRep is encoded as follows:

          <PCRep Message> ::= <Common Header>
                              <response>

          <response> ::= <RP>
                         [<vendor-info-list>]
                         [<end-point-path-pair-list>]
                         [<NO-PATH>]
                         [<attribute-list>]

        where:

           <end-point-path-pair-list> ::=
                          [<END-POINTS>]
                          <path>
                          [<vendor-info-list>]
                          [<end-point-path-pair-list>]

          <path> ::= (<ERO>|<SERO>) [<path>]

          <attribute-list> ::= [<OF>]
                               [<LSPA>]
                               [<BANDWIDTH>]
                               [<metric-list>]
                               [<IRO>]

---