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

[Oscar González de Dios <[e-mail]>]

Forget about last email.. My computer started to get old emails...

-----Mensaje original-----
De: Oscar González de Dios
Enviado el: miércoles, 29 de enero de 2020 17:42
Para: [e-mail]; 'Benjamin Kaduk' <[e-mail]>; 'The IESG' <[e-mail]>
CC: [e-mail]; [e-mail]; [e-mail]
Asunto: RE: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-gmpls-pcep-extensions-15: (with COMMENT)

Hi Adrian,

I can take care of posting (as one of the main editors).

Minor thing, current posted version is -16, so I guess this one should be -17 right?

Oscar

-----Mensaje original-----
De: Adrian Farrel <[e-mail]> Enviado el: jueves, 12 de diciembre de 2019 21:09
Para: 'Benjamin Kaduk' <[e-mail]>; 'The IESG' <[e-mail]>
CC: [e-mail]; [e-mail]; [e-mail]
Asunto: RE: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-gmpls-pcep-extensions-15: (with COMMENT)

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

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição