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

[Lou Berger]

Hi Ina,

On 11/5/2015 6:42 PM, Ina Minei wrote:
> Cyril, 
>
> Thank you for the review and discussion, please see inline ###. 
>
> On Tue, Nov 3, 2015 at 1:09 AM, Cyril Margaria
> > wrote:
>
> 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?
>
>
> ### 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

> 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?
>
> ### Same as above 
>  
>
> 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)
>
>
> ### 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). 
>
>
> Which use cases will not be permitted by that mode of operation?
>
>
>
>
>
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Julien Meuric]

Hi all,

Nov. 05, 2015 - lber...@labn.net:

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

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Cyril Margaria]

please see inline



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

### 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).

[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
 and
draft-ietf-pce-pce-initiated-lsp
 do apply
and are sufficient to do the cleanup.

BR,
Cyril

>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce