Subject: Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-gmpls-pcep-extensions-15: (with COMMENT)

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 12 Dec 2019 20:08:33 -0000

Hi Ben,

In the absence of a response from the authors this last month, I'm jumping
in because I want to see this published.

Authors/shepherd/chairs/AD: attached is an xml file that makes these
changes. I can't post it cos I'm not an author.

Cheers,
Adrian

===

> Thank you for addressing my Discuss points!

Thanks for clearing.

> I do have some additional comments on the -15.

Perfect. I'm trying to answer them below.

> Section 2.3
>
> I'm still a bit concerned that the references linked from Table 4 may not
> provide a clear description of what count as Traffic Parameters for our
> purposes (and how they are encoded), but not in a way that I can express
> more concretely.  Perhaps this is made clear by some RSVP-TE documents
> with which I am not familiar.

Agree that it is pretty convoluted. But I just checked all of the references
and they are clear how to encode the traffic parameters for each of the
different technology types in RSVP-TE. And since the PCEP objects are direct
copies of the RSVP-TE ones, and since they are describing the same things, I
think we are safe.

It's true that it's a lot of reading, but the PCE that supports one of these
bandwidth types must understand the technology as well as an RSVP-TE
implementation that signals one.

I think we're OK on this point.

> Section 2.5.1
>
>   root and other endpoints TLVs are the leaves.  The root endpoint MUST
>   be the same for all END-POINTS objects.  If the root endpoint is not
>
> I'm not sure how broadly scoped this restriction is -- it is, e.g.,
per-LSP?

This is all in the scope of a single PCEP request message for a path. So,
yes, per LSP, but multiple END-POINT objects can be present on one request.
 
So...
OLD
   The root endpoint MUST be the same for all END-POINTS objects.
NEW
   The root endpoint MUST be the same for all END-POINTS objects
   carried in a single PCEP request message.
END

> Section 2.5.2.5
>
>   with L bit cleared.  At most 2 LABEL_SET TLVs MAY be present with the
>   O bit set, with at most one of these having the U bit set and at most
>   one of these having the U bit cleared.  For a given U bit value, if
>
> This went MUST->MAY in this rev, though I think it might be fine to just
use
> a lowercase "may", since the requirements language doesn't map terribly
well
> to the restriction we're making.

I would prefer to make this definitive. I think the language is all mixed
around. How about we do:

OLD
   At most 2 LABEL_SET TLVs MAY be present with the
   O bit set, with at most one of these having the U bit set and at most
   one of these having the U bit cleared.
NEW
   There MUST NOT be more than two LABEL_SET TLVs present with the
   O bit set. If there are two LABEL_SET TLVs present, there MUST NOT
   be more than one with the U bit set, and there MUST NOT be more 
   than one with the U bit cleared.
END