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

From: Lou Berger <[email-masked]>
Date: Tue, 3 Nov 2015 18:13:24 +0900

So responding a bit late, as promised in today's session.  Sorry I
missed your message when first sent.

On 8/21/2015 6:22 PM, Zhangxian (Xian) wrote:
> Hi, Lou,
> 
> Thank you for the useful comments. Let me try to explain to see if we
> can converge before we updating the draft.
> 
> Let me start with the objective of the draft: to define a general
> mechanism that support LSP association via PCEP. So, we confine
> ourselves to having minimum/MUST-have attributes, additional
> information can be added into the optional TLVs if needed as per
> application.
> 

Sure, sounds like the RSVP association object. Of course having a PCE
object and PCEP object with the same name but covering different
function scope seems likely to lead to confusion/issues/conflicts down
the road.

>    Now, to your comments: 
> 
>>     1) Is there a reason to not follow and provide the full function
>>     supported by  RSVP Extended ASSOCIATION Object [RFC6780]?
> 
> [Xian]: By looking at RFC6780, I think the following changes may be
> needed when updating draft-minei-pce-association-group:
> A)	Extending the 4-bit association type to 16 bits;
great - see that
> B)	Currently association ID in draft-minei-pce-association-group-02
> is 32 bits but in RFC6780 16 bits. So, this can be covered, thus no
> need for revision;
> C) Global Association source and extended association ID: is this
> something basic? Or can it be added into the optional TLVs as per
> application? Open to your suggestion on this point and it would be good
> to share your thoughts behind.

The extended association object was defined as a result of the original
object being considered too limited given the scope of applications
making use of it.  Given this experience, I'd be inclined to believe
that the same will happen here.  We're talking control plane bits on the
wire which are relatively cheap, so would lean to learning from the past
experience and cover the same scope/breadth.

>>     2) For Association Source field I suggest:
>>         OLD
>>        An IPv4 or IPv6 address, which
>>        is  associated  to the PCE peer that originated the association.
>>        NEW
>>        An IPv4 or IPv6 address, which
>>        identifies the originator of the association
> 
> [Xian]: This is the part I do not really agree with. At the moment,
> we use this field as a differentiator for error handling. To be more
> specific, depending on whether the association is originated by PCC
> or PCE, we need to decide whether to clear up the association
> information. Relaxing this PCEP object field messes up with the error
> handling we are working on. Another point is: could you also give
> examples where the originator is not a PCE peer, but it will need to
> use PCEP for conveying such information?
> 

I guess I don't understand/see this in the document.  I do see that
there are specific actions to be taken by a PCC/PCE.

As for an example of a non-PCE/PCC originator, there have been
implementations that use a management system (address) to manage
association identifiers and this restriction seems to unnecessarily
preclude such centrally orchestrated solutions.

Lou

> Cheers,
> Xian & Ina
> 
> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]] 
> Sent: 2015年7月27日 19:43
> To: Ina Minei
> Cc: [email-masked]; PCE WG List
> Subject: Re: comments on draft-minei-pce-association-group
> 
> Function.
> 
>  -- but encoding is fine too (and why not?)...
> 
> Lou
> On 07/26/2015 09:19 AM, Ina Minei wrote:
>> Lou, 
>>
>> Thank you for the feedback. Can you clarify the first comment about
>> reuse of the extended association object from RFC6780, are you asking
>> about the object encoding or about the function? 
>>
>> Ina 
>>
>> On Fri, Jul 24, 2015 at 2:02 AM, Lou Berger <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     Authors,
>>     Useful draft & additional function.  I have two comments:
>>
>>     1) Is there a reason to not follow and provide the full function
>>     supported by  RSVP Extended ASSOCIATION Object [RFC6780]?
>>
>>     2) For Association Source field I suggest:
>>         OLD
>>        An IPv4 or IPv6 address, which
>>        is  associated  to the PCE peer that originated the association.
>>        NEW
>>        An IPv4 or IPv6 address, which
>>        identifies the originator of the association
>>
>>     Thanks,
>>     Lou
>>
>>
>