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. 

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

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

Cheers,
Xian & Ina

-----Original Message-----
From: Lou Berger [mailto:[email protected]] 
Sent: 2015年7月27日 19:43
To: Ina Minei
Cc: [email protected]; 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 protected]
> <mailto:[email protected]>> 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
> 
> 

_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce

Reply via email to