Subject: [Pce] Comments on draft-minei-pce-association-group

From: Cyril Margaria <[email-masked]>
Date: Tue, 3 Nov 2015 04:09:08 -0500

Hi,

My comments on the document are:

1)  The format goes in the good,direction, but is not yet fully aligned
with rfc6780, is this planned for a future revision?
2)  My concern is the following statements:

   "For both
   cases, the association is uniquely identified by the combination of
   an association identifier and the address of the PCE peer that
   created the association."

   "Association Source: 4 or 16 bytes - An IPv4 or IPv6 address, which is
   associated to the PCE peer that originated the association."

Those statement are not aligned with the RSVP association is managed.
The reason stated is that the association state is tied to that PCE.

Is this related to the fact that about any PCC/PCE can create
association on a LSP?

3) Association control : the PCC and any PCE can create associations:
 this diverge from the existing mechanism from the statefull document.
In my opinion this aspect makes the control and state maintenance more
complicated. The use cases behind this multiple-controller model is not
very clear.

If the association is under the control a single entity (PCC or PCE), as in
the stateful document, the association state then become part of the PCE
state and the rules described in the stateful document  applies (it up to
the PCE who as delegation to set the association.

This would also allow to get rid of the R bit, as mentioned by adrian (to
remove an association: simply not send it)

Which use cases will not be permitted by that mode of operation?

---

From: Ina Minei <[email-masked]>
Date: Thu, 5 Nov 2015 01:42:31 -0800

Cyril,

Thank you for the review and discussion, please see inline ###.

> with rfc6780, is this planned for a future revision?

### Yes, as we discussed with Loa at the IETF, we are changing the format,
a new version of the document will be published next week.

> Is this related to the fact that about any PCC/PCE can create association on a LSP?
>
> ### Same as above

> If the association is under the control a single entity (PCC or PCE), as
> in the stateful document, the association state then become part of the PCE

### I disagree, the ability to have either create an association and
allocate an identifier was a key requirement (you may recall that version
00 only allowed the PCE to create such associations, and we received a lot
of feedback asking to lift this limitation).

---

From: Lou Berger <[email-masked]>
Date: Fri, 6 Nov 2015 06:35:11 +0900

Hi Ina,

On 11/5/2015 6:42 PM, Ina Minei wrote:
> On Tue, Nov 3, 2015 at 1:09 AM, Cyril Margaria
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     1)  The format goes in the good,direction, but is not yet fully
>     aligned with rfc6780, is this planned for a future revision?
>
>
> ### Yes, as we discussed with Loa at the IETF, we are changing the
> format, a new version of the document will be published next week. 
>  
Loa = Lou = me, right?

To summarize, the changes are basically to:
1) Add the two optional 'extended' parameters introduced in rfc6780 as
optional sub-TLVs
2) change the field sizes to the same as rfc6780
3) to change the association source to be the same as 6780

We also discussed the R bit and I didn't have any objection to it (but
also don't see it as significant either way.)

Thanks for the easy resolution!
Lou

>     In my opinion this aspect makes the control and state maintenance
>     more complicated. The use cases behind this multiple-controller
>     model is not very clear.
>
>     If the association is under the control a single entity (PCC or
>     PCE), as in the stateful document, the association state then
>     become part of the PCE state and the rules described in the
>     stateful document  applies (it up to the PCE who as delegation to
>     set the association.
>
>     This would also allow to get rid of the R bit, as mentioned by
>     adrian (to remove an association: simply not send it)
>
>
> allocate an identifier was a key requirement (you may recall that
> version 00 only allowed the PCE to create such associations, and we
> received a lot of feedback asking to lift this limitation). 
>
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Julien Meuric <[email-masked]>
Date: Fri, 6 Nov 2015 02:34:06 +0100

Hi all,

Nov. 05, 2015 - [email-masked]:
> Loa = Lou = me

Does it mean we've all been abused by this fake beard for years?!

Anyway, than you for working together during adoption polling: that is a 
strong move to build the consensus we are trying to judge there.

Regards,

Julien

---

From: Cyril Margaria <[email-masked]>
Date: Fri, 6 Nov 2015 11:15:31 +0900

please see inline

<cut>

[MC] I mixed different things here, some of them were clarified during the
discussion:
  -a)  Multiple-controller : I meant multiple PCE at the same time, the
authors clarified that only one PCE can set the association, the one having
the delegation.
    This is  implicit because only PCUpd and PCInitiate can change the
association, Additional text could make it more clear, that address the "This
diverge from the existing mechanism from the statefull document."
  b) I agree that the ability to have either create an association and
allocate an identifier is a key requirement, this should be kept.
        Do you mean that the R bit is required to do that? I did not find
this in the document. I have the view as Lou on it.
  c) Cleanup-procedure : this is addressed by the comment "3) to change the
association source to be the same as 6780" from Lou: as the state is not
per association source/PCE and point a), then the Associations is another
PCE-create parameter, so the draft-ietf-pce-stateful-pce
<http://tools.ietf.org/wg/pce/draft-ietf-pce-stateful-pce/> and
draft-ietf-pce-pce-initiated-lsp
<http://tools.ietf.org/wg/pce/draft-ietf-pce-pce-initiated-lsp/> do apply
and are sufficient to do the cleanup.

BR,
Cyril

---

From: Ina Minei <[email-masked]>
Date: Mon, 9 Nov 2015 12:38:05 -0800

Apologies for the awful spelling, and many thanks for the feedback.

The changes we discussed are now incorporated into version 04 of the draft
at
https://www.ietf.org/internet-drafts/draft-minei-pce-association-group-04.txt

Ina