Hi Adrian,
Thanks for your review and suggestions. I could not get to this earlier,
apologies for that! Please see inline...
Diff:
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-pce-association-group-04.txt=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-05.txt
Txt:
https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-ietf-pce-association-group-05.txt
> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
> Sent: 05 February 2018 01:22
> To: pce@ietf.org
> Subject: Re: [Pce] WG LC of draft-ietf-pce-association-group
>
> This is an important piece of work and there are a number of drafts
> dependent on it that will provide useful function. So we should definitely
> push forward to publication, but we also have to get this foundational
> document right otherwise we will struggle later.
>
> I have some moderate-sized issues set out below. Most just need editorial
> work although a couple are more substantive technical points that may need
> changes or better explanation.
>
> Thanks for the work.
>
> Adrian
>
> ---
>
> I spent a lot of time trying to understand the relationship between the
> svec-list and the association group. This understanding was not enhanced
> by this document since the mention of svec is actually only in the RBNF in
> section 5.2.2. I think the only thing to do to make this clear is to add a
> specific section "Relationship with the SVEC List" and use that to explain
> how the two constructs relate.
>
> Now, I know that this document doesn't define any Association Types, and
> that might mean that you think you don't have to describe the
> relationship: "It is up to the documents that define individual
> Association Types," you may say. But I think you have to give some
> guidance in this document since you are defining a mechanism that is at
> last superficially similar. And certainly some (but not all) of the
> motivations in 3.1 might be achieved using SVEC.
>
[[Dhruv Dhody]] I don't see a harm in tackling with SVEC in this document. I
have added -
3.2. Relationship with the SVEC List
Note that, [RFC5440] defines a mechanism for the synchronization of a
set of path computation requests by using the SVEC (Synchronization
VECtor) object, that specifies the list of synchronized requests that
can either be dependent or independent. The SVEC object identify the
relationship between the set of path computation requests, identified
by 'Request-ID-number' in RP (Request Parameters) object. [RFC6007]
further clarifies the use of the SVEC list for synchronized path
computations when computing dependent requests as well as describes a
number of usage scenarios for SVEC lists within single-domain and
multi-domain environments.
The motivation behind the association group defined in this document
and the SVEC object are quite different. The PCEP extensions that
defines new association type, should clarify the relationship between
SVEC object and association type, if any.
Let me know if you wish to add anything else?
> ---
>
> You don't make a lot of mention of RFC 6780. In fact, you only use it to
> define the association source. I think you need to describe how the PCEP
> Association maps to the RSVP-TE Association at least at a high level.
> (Again, I hear you saying that is an issue for the subsequent documents,
> but I think you have to give a framework.
>
[[Dhruv Dhody]] Sure, I have added -
[RFC6780] defines the RSVP ASSOCIATION object, which was defined in
the context of GMPLS- controlled Label Switched Paths (LSPs) to be
used to associate recovery LSPs with the LSP they are protecting.
This object also has broader applicability as a mechanism to
associate RSVP state and [RFC6780] described how the ASSOCIATION
object can be more generally applied.
...
5.2. Relationship with the RSVP ASSOCIATION
The format of PCEP ASSOCIATION Object defined in this document, is
aligned with the RSVP ASSOCIATION object ([RFC6780]). Various
Association-Types related to RSVP association are defined in
[RFC4872], [RFC4873], and [RFC7551]. The PCEP extensions that
defines new association type, should clarify how the PCEP association
would work with RSVP association and vice-versa.
> ---
>
> Why is there a different timeout for association state and LSP state?
>
> You have
>
>Association Timeout Interval: when a PCEP session is terminated, a
>PCC waits for this time period before deleting associations created
>by the PCEP peer.
>
> and
>
>The association are properties of the LSP and thus could be stored in
>the LSP state database. The dynamic association exist as long as the
>LSP state. In case of PCEP session termination, the LSP state clean
>up SHOULD also take care of associations.
>
> Section 5.3 is not altogether clear and I suspect
