Hi Cyril,

Thanks for your review and suggestions. I could not get to this earlier, 
apologies for that! Please see inline...


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Cyril Margaria
Sent: 02 February 2018 04:54
To: LITKOWSKI Stephane DTF/DERX <stephane.litkow...@orange.com>
Cc: pce@ietf.org
Subject: Re: [Pce] WG LC of draft-ietf-pce-association-group


I support the feature, I have the following comment regarding the draft:
  - There is not mandated capability negotiation, this generally makes 
interworking more cumbersome.
  This could be resolved by mandating the presence of  OP-CONF-ASSOC-RANGE, and 
using reserved value 0,0 for  Start-Assoc-ID, Range to indicate that there is no

Operator-configured Association Range.

[[Dhruv Dhody]] The presence of ASSOCIATION object in PCEP message is a good 
indicator for this feature. Not sure if there is a need to exchange 
capabilities in OPEN, we have followed the similar approach in RFC5455, 5520, 
5521 etc.

Section 4.1 : what happens if the dynamic allocation ranges do not match 
between the two peer ? is it allowed or should the session be bounced?

  A special case can be made when one peer advertise (0,0)

[[Dhruv Dhody]] I have added an appendix with an example to make this clearer, 
please let me know if I need to make any change for this!

section 5.2.1:

 - the PCC can remove an association by setting the R flag to 1, if the PCC 
does not include any association, should the association be kept on the LSP?

[[Dhruv Dhody]] The R flag is set in association, if association id is zero, 
that is invalid; if association id is 0xffff, then it is all association within 
the scope of association type/source; otherwise it looks for association, if 
not found it is considered as unknown association.

 - I think the following should be added : PCRpt: all associations MUST be 
reported during state synchronization

[[Dhruv Dhody]] Ack.

 - Value 0 was previously used to ask a peer to allocate an association ID. Is 
it deemed not necessary anymore.

[[Dhruv Dhody]] Yes

Section 5.3:

 - the "association information" is not defined. The whole section can be 
clarified by detailing what the association information is.:

is it (association type, association source, association-id), from the 
association group definitions, the triplet defines a group, so it should be 
possible to have several association id for th same type, source

[[Dhruv Dhody]] I have added a new section on it, also clarified “association 
information” and “association parameters” in section 5.3

Does the the "association information previously received about the same 
association from a peer" relates to the association group (should there be an 
unique association id per lsp for a given type,source)

or does it refers to the optional TLVs.


   On receiving association

   information that does not match with the association information

   previously received about the same association from a peer, it MUST

   return a PCErr message with Error-Type TBD "Association Error" and

   Error-Value 6 "Association information mismatch""

[[Dhruv Dhody]] it is latter, I have updated!

This could be clarified, IMHO generally speaking the draft should allow several 
association id per (type, source), this kind of restriction may be defined in 
the documents defining the association types.

[[Dhruv Dhody]] Please check the diff and let me know if there is scope of any 
other improvement.

Thanks for your patience.



Thanks, Cyril

On 1 February 2018 at 10:38, 
<stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>> wrote:

-----Original Message-----
From: Pce [mailto:pce-boun...@ietf.org<mailto:pce-boun...@ietf.org>] On Behalf 
Of Julien Meuric
Sent: Thursday, February 01, 2018 15:10
To: pce@ietf.org<mailto:pce@ietf.org>
Subject: [Pce] WG LC of draft-ietf-pce-association-group

Hi all,

This message initiates a 2-week WG last call for 
draft-ietf-pce-association-group-04. Please review and share your feedback on 
the PCE mailing list. This LC will end on Thursday February, 15.


Jon & Julien

Pce mailing list


Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Pce mailing list

Pce mailing list

Reply via email to