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

[Dhruv Dhody <[e-mail]>]

Hi Martin,

Thanks for further discussion, see in-line..

<snip>
> >
> >
> >> 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.
>
> 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.
>

[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.

>
> 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?
>

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>
> >
> >> 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).
>
> That doesn't really clarify. What is the difference between unknown and
> not supported?

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>
> > 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