Subject: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-association-group-09: (with COMMENT)

From: Martin Vigoureux via Datatracker <[email-masked]>
Date: Tue, 09 Jul 2019 14:02:59 -0700

Martin Vigoureux has entered the following ballot position for
draft-ietf-pce-association-group-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-association-group/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

thanks for this document, here are a couple of comments/questions.

   The PCEP ASSOC-Type-List TLV is optional.  It MAY be carried within
   an OPEN object sent by a PCEP speaker in an Open message to a PCEP
   peer so as to indicate the list of supported Association types.
This is said twice. (First paragraph of section 4.1) and then in 4.1.1:
   A PCEP speaker MAY include an ASSOC-Type-List TLV within an OPEN
   object in an Open message sent to a PCEP peer in order to advertise a
   set of one or more supported association types.
   The use of ASSOC-Type-List TLV is OPTIONAL.

It doesn't hurt, but you might want to consider saying this only once. Also I
note OPTIONAL vs optional

Sending ASSOC-Type-List TLV is optional but it might be mandatory to send some
to-be-defined Association types. Isn't that somehow conflicting?

The PCEP OP-CONF-ASSOC-RANGE TLV is optional.
OPTIONAL?

Could you clarify the difference between
a PCEP speaker does not recognize the ASSOCIATION object
and
a PCE peer is ... unable to process the ASSOCIATION
I see that the errors thrown are different.

Nits:
s/protections LSPs/protection LSPs/
s/The Assoc-type MAY appear more than once/A given Assoc-type MAY appear more
than once/ s/to uniquely identifying/to uniquely identify/

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 10 Jul 2019 13:18:53 +0000

Hi Martin,

Thanks for your review. See inline...

> It doesn't hurt, but you might want to consider saying this only once.
> Also I note OPTIONAL vs optional
> 
[[Dhruv Dhody]] Ack. 

> Sending ASSOC-Type-List TLV is optional but it might be mandatory to send
> some to-be-defined Association types. Isn't that somehow conflicting?
> 
[[Dhruv Dhody]] The aim was to say that right now this TLV is optional, but a future association type (say disjoint) can specify that if you want to use *this particular association type* you need to include the TLV. So if an implementation does not support this particular association type, the TLV would be optional, and if it needs to support this, then the TLV becomes mandatory to include.  

> The PCEP OP-CONF-ASSOC-RANGE TLV is optional.
[[Dhruv Dhody]] Ack.

> Could you clarify the difference between a PCEP speaker does not recognize
> the ASSOCIATION object and a PCE peer is ... unable to process the
> ASSOCIATION I see that the errors thrown are different.
> 
[[Dhruv Dhody]] The difference is between ASSOCIATION Object being unknown (former) and Object being known *but* not supported/processed (latter).  

> s/The Assoc-type MAY appear more than once/A given Assoc-type MAY appear
> more than once/ s/to uniquely identifying/to uniquely identify/
> 
>
[[Dhruv Dhody]] Ack. 
 
Working Copy: https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-10.txt
Diff: https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-association-group-09&url2=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-10.txt

Thanks! 
Dhruv

> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Wed, 10 Jul 2019 15:45:32 +0000

Dhruv,

thanks for your feedback.

Please see in-line

> [[Dhruv Dhody]] The aim was to say that right now this TLV is optional, but a future association type (say disjoint) can specify that if you want to use *this particular association type* you need…

I understand the aim, but I fail to understand how it doesn't lead to 
conflicting requirements.
This doc says, the whole TLV is optional.
A future doc might say: this assoc-type in this TLV is mandatory.

By construction the future doc is thus saying that the TLV is mandatory, 
which conflicts with the base spec.

Couldn't you lay out the path for the future by saying something like:
* MUST be sent if it contains at least an assoc-type which must be sent 
and MAY NOT be sent otherwise.

As a side question, sorry I didn't go back to the doc, but how should 
the systems behave in the case where there are two assoc types: one 
mandatory and the other not.
MUST the system advertise both in the list or can it only advertise the 
mandatory one? And how will the receiver treat that latter case? I'm 
asking because I think you cover the case of not sending the whole TLV 
and then the receiver MUST interpret that as an absence of information 
on the list of supported Association types (rather than the Association 
type is not supported), but if it receives the TLV without the assoc 
type, should it still interpret it as an absence of info or as not 
supported?

> [[Dhruv Dhody]] The difference is between ASSOCIATION Object being unknown (former) and Object being known *but* not supported/processed (latter).

That doesn't really clarify. What is the difference between unknown and 
not supported?

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 10 Jul 2019 23:45:58 +0530

Hi Martin,

Thanks for further discussion, see in-line..

<snip>
> and MAY NOT be sent otherwise.

[Dhruv]: I agree, I can update the text to say -

   Association type (to be defined in other documents) can specify if
   the association type advertisement is mandatory for it.  Thus, the
   ASSOC-Type-List TLV MUST be included if at least one mandatory
   association type needs to be advertised and the ASSOC-Type-List TLV
   MAY be included otherwise.

I used MAY, as MAY NOT is not RFC 2119 keyword.

> type, should it still interpret it as an absence of info or as not

We have this text in the I-D that covers these conditions -

   For an association type that specifies
   that the advertisement is mandatory, a missing Assoc-type in the
   ASSOC-Type-List TLV (or missing ASSOC-Type-List TLV) is to be
   interpreted as the association type is not supported by the PCEP
   speaker.

   The absence of the ASSOC-Type-List TLV in an OPEN object MUST be
   interpreted as an absence of information on the list of supported
   Association types (rather than the Association type is not
   supported).  In this case, the PCEP speaker could still use the
   ASSOCIATION object: if the peer does not support the association, it
   will react as per the procedure described in Section 6.4.

   In case the use of the ASSOC-Type-List TLV is triggered by support
   for a mandatory association type, then it is RECOMMENDED that the
   PCEP implementation include all supported Association types
   (including optional) to ease the operations of the PCEP peer.

<snip>
> That doesn't really clarify. What is the difference between unknown and

Unknown - I parse the PCEP object header, and find an object-type, I
dont know what this object type means and it is unknown.
Not Supported - I parse the PCEP object header, and find an
object-type that i am aware of but for some reason do not support.
This could be because of feature being disabled via configuration for
instance.

Note that these errors are defined in PCEP since its inception in RFC 5440.

Last Commit: https://github.com/dhruvdhody-huawei/ietf/commit/a00b161661a334d800bab99dedbd2012e3951651

Please let me know if any further change is needed.

Thanks!
Dhruv

<snip>

---

From: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Wed, 10 Jul 2019 18:25:16 +0000

Dhruv,

thanks in return for discussing these comments.

Thanks for the new paragraph, and thanks for pointing me to what I 
should have found myself.

on the unsupported/unknown, it is clearer now. Thanks.

-m