Re: [Pce] WG LC of draft-ietf-pce-association-group

2018-09-18 Thread Cyril Margaria
Hi,

This update addresses my comments, including the recommended capability
advertisement.

Thanks,
Cyril

On 6 September 2018 at 01:39, Julien Meuric 
wrote:

> Hi all,
>
> I have not seen any feedback on the update below. We will thus consider
> that everyone is fine with the optional advertisement which has been added.
>
> Cyril, you raised the issue: could you please confirm this update
> addresses your comment?
>
> Thanks,
>
> Julien
>
>
> Jun. 19, 2018 - Dhruv Dhody:
>
> Hi WG,
>
> We have posted an update to the association group draft that handle the
> final pending issue regarding capability advertisement.
> See the update - https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-
> association-group-06
>
> Hope the document can be sent to IESG soon!
>
> Thanks!
> Dhruv
>
> On Thu, Apr 26, 2018 at 4:33 PM Dhruv Dhody 
> wrote:
>
>> Hi Cyril,
>>
>>
>>
>> Thanks for engaging, please see inline *[[Dhruv Dhody2]]*
>>
>>
>>
>> Working Copy:
>>
>> Diff: https://tools.ietf.org/rfcdiff?url1=https://tools.
>> ietf.org/id/draft-ietf-pce-association-group-05.txt=
>> https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/
>> master/draft-ietf-pce-association-group-06.txt
>> <https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-pce-association-group-05.txt=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-06..txt>
>>
>> Txt: https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-
>> ietf-pce-association-group-06.txt
>>
>>
>>
>>
>>
>> Dhruv Dhody
>>
>> Lead Architect
>>
>> Network Business Line
>>
>> Huawei Technologies India Pvt. Ltd.
>>
>> Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield
>>
>> Bengaluru, Karnataka - 560066
>>
>> Tel: + 91-80-49160700 Ext 71583 II Email: dhruv.dh...@huawei.com
>>
>> [image: Huawei-small]
>>
>> This e-mail and its attachments contain confidential information from
>> HUAWEI, which
>> is intended only for the person or entity whose address is listed above.
>> Any use of the
>> information contained herein in any way (including, but not limited to,
>> total or partial
>> disclosure, reproduction, or dissemination) by persons other than the
>> intended
>> recipient(s) is prohibited. If you receive this e-mail in error, please
>> notify the sender by
>> phone or email immediately and delete it!
>>
>>
>>
>> *From:* Cyril Margaria [mailto:cyril.marga...@gmail..com
>> ]
>> *Sent:* 26 April 2018 00:13
>> *To:* Dhruv Dhody 
>> *Cc:* LITKOWSKI Stephane DTF/DERX ; Dhruv
>> Dhody ; pce@ietf.org
>> *Subject:* Re: [Pce] WG LC of draft-ietf-pce-association-group
>>
>>
>>
>> Hi,
>>
>>
>>
>> Thanks for the prompt reply, sorry for the not-so-prompt handling of that.
>>
>> Please see inline
>>
>>
>>
>> On 23 February 2018 at 08:51, Dhruv Dhody  wrote:
>>
>> Hi Cyril,
>>
>>
>>
>> Thanks for your review and suggestions. I could not get to this earlier,
>> apologies for that! Please see inline...
>>
>>
>>
>> Diff: https://tools.ietf.org/rfcdiff?url1=https://tools.
>> ietf.org/id/draft-ietf-pce-association-group-04.txt=
>> https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/
>> master/draft-ietf-pce-association-group-05.txt
>> <https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-pce-association-group-04.txt=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-05..txt>
>>
>> Txt: https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-
>> ietf-pce-association-group-05.txt
>>
>>
>>
>> *From:* Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Cyril Margaria
>> *Sent:* 02 February 2018 04:54
>> *To:* LITKOWSKI Stephane DTF/DERX 
>> *Cc:* pce@ietf.org
>> *Subject:* Re: [Pce] WG LC of draft-ietf-pce-association-group
>>
>>
>>
>> Hi,
>>
>>
>>
>> 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.
>>
>>
>>
>&

Re: [Pce] WG LC of draft-ietf-pce-association-group

2018-09-06 Thread Julien Meuric

  
  
Hi all,

I have not seen any feedback on the update below. We will thus
consider that everyone is fine with the optional advertisement which
has been added.

Cyril, you raised the issue: could you please confirm this update
addresses your comment?

Thanks,

Julien


Jun. 19, 2018 - Dhruv Dhody:


  
  
Hi WG, 


We have posted an
  update to the association
  group draft that handle the final pending issue regarding
  capability advertisement. 
See the update - https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-group-06



Hope the document can
  be sent to IESG soon! 


Thanks! 
Dhruv
  
  
  
On Thu, Apr 26, 2018 at 4:33 PM Dhruv Dhody <dhruv.dh...@huawei.com>
  wrote:


  

  Hi Cyril,

   
  Thanks for
  engaging, please see inline
  [[Dhruv Dhody2]]
   
  Working Copy:
  Diff:
  
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-pce-association-group-05.txt=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-06.txt
  Txt:
  
https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-ietf-pce-association-group-06.txt
   
  
 
  
  Dhruv
  Dhody

  Lead
  Architect
  Network
  Business Line
  Huawei
  Technologies India Pvt. Ltd.
  Survey
  No. 37, Next to EPIP Area, Kundalahalli, Whitefield
  Bengaluru,
  Karnataka - 560066

  Tel:
  + 91-80-49160700 Ext 71583 II Email:
dhruv.dh...@huawei.com
  

  
  This
  e-mail and its attachments contain confidential
  information from HUAWEI, which
  
  is intended only for the person or entity whose
  address is listed above. Any use of the
  
  information contained herein in any way (including,
  but not limited to, total or partial
  
  disclosure, reproduction, or dissemination) by persons
  other than the intended 
  recipient(s) is prohibited. If you receive this e-mail
  in error, please notify the sender by
  
  phone or email immediately and delete it!
   
  

  
From:
Cyril Margaria [mailto:cyril.marga...@gmail..com]

Sent: 26 April 2018 00:13
To: Dhruv Dhody <dhruv.dh...@huawei.com>
Cc: LITKOWSKI Stephane DTF/DERX <stephane.litkow...@orange.com>;
Dhruv Dhody <dhruv.i...@gmail.com>;
pce@ietf.org
                Subject: Re: [Pce] WG LC of
        draft-ietf-pce-association-group
  

 

  Hi, 
  
 
  
  
Thanks for the prompt reply,
  sorry for the not-so-prompt handling of that.
  
  
Please see inline
  
  
 

  On 23 February 2018 at 08:51,
Dhruv Dhody <dhruv.dh...@huawei.com>
wrote:
  

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

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-pce-association-group-04.txt=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-05.txt
Txt:

https://git

Re: [Pce] WG LC of draft-ietf-pce-association-group

2018-06-18 Thread Dhruv Dhody
Hi WG,

We have posted an update to the association group draft that handle the
final pending issue regarding capability advertisement.
See the update -
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-group-06

Hope the document can be sent to IESG soon!

Thanks!
Dhruv

On Thu, Apr 26, 2018 at 4:33 PM Dhruv Dhody  wrote:

> Hi Cyril,
>
>
>
> Thanks for engaging, please see inline *[[Dhruv Dhody2]]*
>
>
>
> Working Copy:
>
> Diff:
> https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-pce-association-group-05.txt=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-06.txt
>
> Txt:
> https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-ietf-pce-association-group-06.txt
>
>
>
>
>
> Dhruv Dhody
>
> Lead Architect
>
> Network Business Line
>
> Huawei Technologies India Pvt. Ltd.
>
> Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield
>
> Bengaluru, Karnataka - 560066
>
> Tel: + 91-80-49160700 Ext 71583 II Email: dhruv.dh...@huawei.com
>
> [image: Huawei-small]
>
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
>
>
>
> *From:* Cyril Margaria [mailto:cyril.marga...@gmail.com]
> *Sent:* 26 April 2018 00:13
> *To:* Dhruv Dhody 
> *Cc:* LITKOWSKI Stephane DTF/DERX ; Dhruv
> Dhody ; pce@ietf.org
> *Subject:* Re: [Pce] WG LC of draft-ietf-pce-association-group
>
>
>
> Hi,
>
>
>
> Thanks for the prompt reply, sorry for the not-so-prompt handling of that..
>
> Please see inline
>
>
>
> On 23 February 2018 at 08:51, Dhruv Dhody  wrote:
>
> Hi Cyril,
>
>
>
> Thanks for your review and suggestions. I could not get to this earlier,
> apologies for that! Please see inline...
>
>
>
> Diff:
> https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-pce-association-group-04.txt=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-05.txt
>
> Txt:
> https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-ietf-pce-association-group-05.txt
>
>
>
> *From:* Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Cyril Margaria
> *Sent:* 02 February 2018 04:54
> *To:* LITKOWSKI Stephane DTF/DERX 
> *Cc:* pce@ietf.org
> *Subject:* Re: [Pce] WG LC of draft-ietf-pce-association-group
>
>
>
> Hi,
>
>
>
> 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.  *
>
>  [MC] Peer capability discovery is supported in RFC5541, RFC8281,
> RFC6006. The ability to know which type of association (bidirectional LSP,
> path protection,..etc) is supported affect the Path Computation,
>
>and in addition the reception of an unknown object will close the
> session, which is less than ideal at scale.
>
>  If the  OP-CONF-ASSOC-RANGE is not meaningful, then a TLV for discovery
> is needed (list of association source and reserved flags for draft use
> would be ideal)
>
>
>
> *[[Dhruv Dhody2]] I can’t think of way to introduce this in a backward
> compatible way that would work with existing association implementations.
> Let me talk to the chairs on the resolving this! *
>
>
>
>
>
> 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! *
>
>
>
> The example helps, maybe the following change in version 5, section 3.4
> would clarify 

Re: [Pce] WG LC of draft-ietf-pce-association-group

2018-04-25 Thread Cyril Margaria
Hi,

Thanks for the prompt reply, sorry for the not-so-prompt handling of that.
Please see inline

On 23 February 2018 at 08:51, Dhruv Dhody <dhruv.dh...@huawei.com> wrote:

> Hi Cyril,
>
>
>
> Thanks for your review and suggestions. I could not get to this earlier,
> apologies for that! Please see inline...
>
>
>
> Diff: https://tools.ietf.org/rfcdiff?url1=https://tools.
> ietf.org/id/draft-ietf-pce-association-group-04.txt=
> https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/
> master/draft-ietf-pce-association-group-05.txt
>
> Txt: https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-
> ietf-pce-association-group-05.txt
>
>
>
> *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
>
>
>
> Hi,
>
>
>
> 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.  *
>
>  [MC] Peer capability discovery is supported in RFC5541, RFC8281,
RFC6006. The ability to know which type of association (bidirectional LSP,
path protection,..etc) is supported affect the Path Computation,
   and in addition the reception of an unknown object will close the
session, which is less than ideal at scale.
 If the  OP-CONF-ASSOC-RANGE is not meaningful, then a TLV for discovery is
needed (list of association source and reserved flags for draft use would
be ideal)

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! *
>
>
>
> The example helps, maybe the following change in version 5, section 3.4
would clarify further:
OLD:

   A range of association identifier for each association-type are kept
   for the operator-configured associations.  Dynamic associations MUST
   NOT use the association identifier from this range.

   This range as set at the PCEP speaker (as an association source)
   needs to be communicated to a PCEP peer in the Open Message.  A new
   TLV is defined in this specification for this purpose (Section 4
<https://tools.ietf.org/html/draft-ietf-pce-association-group-05#section-4>).
   See Appendix A
<https://tools.ietf.org/html/draft-ietf-pce-association-group-05#appendix-A>
for an example.

NEW:

   A range of association identifier for each
association-type,association-source are kept
   for the operator-configured associations.  Dynamic associations MUST
   NOT use the association identifier from this range.

   This range as set at the PCEP speaker (PCC or PCE) and
   needs to be communicated to a PCEP peer in the Open Message.  A new
   TLV is defined in this specification for this purpose (Section 4
<https://tools.ietf.org/html/draft-ietf-pce-association-group-05#section-4>).
   See Appendix A
<https://tools.ietf.org/html/draft-ietf-pce-association-group-05#appendix-A>
for an example.


   Association identifier range for sources other than the PCEP peer
(an NMS system for example) is outside the scope of this document,

--





> 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 0x, 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. *
>
>
So


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

Re: [Pce] WG LC of draft-ietf-pce-association-group

2018-03-20 Thread Adrian Farrel
Very bad of me to be so late responding. I have put aside all minor wrinkles
because of that.

But...

> > 5.1
> >
> >R (Removal - 1 bit):  when set, the requesting PCE peer requires the
> >   removal of an LSP from the association group.  This flag is used
> >   for ASSOCIATION object in PCRpt and PCUpd message, the flag is
> >   ignored in other PCEP messages.
> >
> > What does R==0 signify?
> >
> [[Dhruv Dhody]] Not removal! :)
> Do you see a need for some text here? (This would be similar to R flag in LSP
> object for PCRpt?)

Possible meanings are...

"PCE peer requires retention"
"PCE peer does not require removal"
"PCE peer requests removal"
"PCE peer requests retention"

You should say!

> > 5.3
> >
> > Presumably if the R bit is set and the LSP was not in the association, we
> > act as though it had been and we had removed it?
> >
> [[Dhruv Dhody]] We have this text in the draft -
> 
>If a PCEP speaker receives ASSOCIATION object with R bit set for
>removal, and the association group (identified by association
>parameters) is not known, it MUST return a PCErr message with Error-
>Type 26 (Early allocation by IANA) "Association Error" and Error-
>Value 4 "Association unknown".
> 
> Since this LSP is not in the association, we considered this as an association
not
> known in the context of the LSP and re-used the error. If this is not clear we
could
> define a new error-value instead?

It works, but seems suboptimal. 
The intent is "make the group no longer contain the LSP".
The sender now has to handle two "success" results:
1. working as normal
2. this error case

Thanks for the work,
Adrian

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


Re: [Pce] WG LC of draft-ietf-pce-association-group

2018-02-23 Thread Dhruv Dhody
Hi Adrian, 

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

Diff: 
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-pce-association-group-04.txt=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-05.txt
Txt: 
https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-ietf-pce-association-group-05.txt

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
> Sent: 05 February 2018 01:22
> To: pce@ietf.org
> Subject: Re: [Pce] WG LC of draft-ietf-pce-association-group
> 
> This is an important piece of work and there are a number of drafts
> dependent on it that will provide useful function. So we should definitely
> push forward to publication, but we also have to get this foundational
> document right otherwise we will struggle later.
> 
> I have some moderate-sized issues set out below. Most just need editorial
> work although a couple are more substantive technical points that may need
> changes or better explanation.
> 
> Thanks for the work.
> 
> Adrian
> 
> ---
> 
> I spent a lot of time trying to understand the relationship between the
> svec-list and the association group. This understanding was not enhanced
> by this document since the mention of svec is actually only in the RBNF in
> section 5.2.2. I think the only thing to do to make this clear is to add a
> specific section "Relationship with the SVEC List" and use that to explain
> how the two constructs relate.
> 
> Now, I know that this document doesn't define any Association Types, and
> that might mean that you think you don't have to describe the
> relationship: "It is up to the documents that define individual
> Association Types," you may say. But I think you have to give some
> guidance in this document since you are defining a mechanism that is at
> last superficially similar. And certainly some (but not all) of the
> motivations in 3.1 might be achieved using SVEC.
> 
[[Dhruv Dhody]] I don't see a harm in tackling with SVEC in this document. I 
have added - 

3.2.  Relationship with the SVEC List

   Note that, [RFC5440] defines a mechanism for the synchronization of a
   set of path computation requests by using the SVEC (Synchronization
   VECtor) object, that specifies the list of synchronized requests that
   can either be dependent or independent.  The SVEC object identify the
   relationship between the set of path computation requests, identified
   by 'Request-ID-number' in RP (Request Parameters) object.  [RFC6007]
   further clarifies the use of the SVEC list for synchronized path
   computations when computing dependent requests as well as describes a
   number of usage scenarios for SVEC lists within single-domain and
   multi-domain environments.

   The motivation behind the association group defined in this document
   and the SVEC object are quite different.  The PCEP extensions that
   defines new association type, should clarify the relationship between
   SVEC object and association type, if any.

Let me know if you wish to add anything else? 

> ---
> 
> You don't make a lot of mention of RFC 6780. In fact, you only use it to
> define the association source. I think you need to describe how the PCEP
> Association maps to the RSVP-TE Association at least at a high level.
> (Again, I hear you saying that is an issue for the subsequent documents,
> but I think you have to give a framework.
> 
[[Dhruv Dhody]] Sure, I have added - 

   [RFC6780] defines the RSVP ASSOCIATION object, which was defined in
   the context of GMPLS- controlled Label Switched Paths (LSPs) to be
   used to associate recovery LSPs with the LSP they are protecting.
   This object also has broader applicability as a mechanism to
   associate RSVP state and [RFC6780] described how the ASSOCIATION
   object can be more generally applied.

...

5.2.  Relationship with the RSVP ASSOCIATION

   The format of PCEP ASSOCIATION Object defined in this document, is
   aligned with the RSVP ASSOCIATION object ([RFC6780]).  Various
   Association-Types related to RSVP association are defined in
   [RFC4872], [RFC4873], and [RFC7551].  The PCEP extensions that
   defines new association type, should clarify how the PCEP association
   would work with RSVP association and vice-versa.

> ---
> 
> Why is there a different timeout for association state and LSP state?
> 
> You have
> 
>Association Timeout Interval: when a PCEP session is terminated, a
>PCC waits for this time period before deleting associations created
>by the PCEP peer.
> 
> and
> 
>The association are properties of the LSP and thus could be stored in
>the LSP state database.  The dynamic association ex

Re: [Pce] WG LC of draft-ietf-pce-association-group

2018-02-19 Thread Dhruv Dhody
Hi,

Thanks Adrian and Cyril, i will work on handles Ng the comments this week.

Regards,
Dhruv

On Mon, 19 Feb 2018 at 10:00 PM, Adrian Farrel <adr...@olddog.co.uk> wrote:

> In case you all missed it, I also made some comments.
>
> https://mailarchive.ietf.org/arch/msg/pce/QSobS2pul-lIlMLXV4KcBhwgBM0
>
> Adrian
>
> > -Original Message-
> > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
> > Sent: 19 February 2018 10:48
> > To: pce@ietf.org
> > Subject: Re: [Pce] WG LC of draft-ietf-pce-association-group
> >
> > Hi,
> >
> > This WG LC has ended. Authors, some comments have been raised (at least
> > by Cyril): please address them.
> >
> > Thanks,
> >
> > Jon & Julien
> >
> >
> > Feb. 01, 2018 - Julien Meuric:
> > > 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.
> > >
> > > Regards,
> > >
> > > Jon & Julien
> > >
> > > ___
> > > 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
>
> ___
> 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] WG LC of draft-ietf-pce-association-group

2018-02-19 Thread Adrian Farrel
In case you all missed it, I also made some comments.

https://mailarchive.ietf.org/arch/msg/pce/QSobS2pul-lIlMLXV4KcBhwgBM0

Adrian

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
> Sent: 19 February 2018 10:48
> To: pce@ietf.org
> Subject: Re: [Pce] WG LC of draft-ietf-pce-association-group
> 
> Hi,
> 
> This WG LC has ended. Authors, some comments have been raised (at least
> by Cyril): please address them.
> 
> Thanks,
> 
> Jon & Julien
> 
> 
> Feb. 01, 2018 - Julien Meuric:
> > 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.
> >
> > Regards,
> >
> > Jon & Julien
> >
> > ___
> > 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

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


Re: [Pce] WG LC of draft-ietf-pce-association-group

2018-02-19 Thread Julien Meuric
Hi,

This WG LC has ended. Authors, some comments have been raised (at least
by Cyril): please address them.

Thanks,

Jon & Julien


Feb. 01, 2018 - Julien Meuric:
> 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.
>
> Regards,
>
> Jon & Julien
>
> ___
> 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] WG LC of draft-ietf-pce-association-group

2018-02-15 Thread Aissaoui, Mustapha (Nokia - CA/Ottawa)
I meant I support the last call for this document 

Mustapha.

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Aissaoui, Mustapha (Nokia 
- CA/Ottawa)
Sent: Thursday, February 15, 2018 6:27 PM
To: Julien Meuric <julien.meu...@orange.com>; pce@ietf.org
Subject: Re: [Pce] WG LC of draft-ietf-pce-association-group

Dear all,
I support this becoming a working group document.

Regards,
Mustapha.

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
Sent: Thursday, February 1, 2018 9:10 AM
To: 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.

Regards,

Jon & Julien

___
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
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


Re: [Pce] WG LC of draft-ietf-pce-association-group

2018-02-15 Thread Aissaoui, Mustapha (Nokia - CA/Ottawa)
Dear all,
I support this becoming a working group document.

Regards,
Mustapha.

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
Sent: Thursday, February 1, 2018 9:10 AM
To: 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.

Regards,

Jon & Julien

___
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] WG LC of draft-ietf-pce-association-group

2018-02-09 Thread Rakesh Gandhi (rgandhi)
Hi Julien, WG,

Yes/support. Very important base document for many other documents for LSP 
association (such as draft-barth-pce-association-bidir).

Thanks,
Rakesh


On 2018-02-01, 9:09 AM, "Pce on behalf of Julien Meuric"  wrote:

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.

Regards,

Jon & Julien

___
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] WG LC of draft-ietf-pce-association-group

2018-02-04 Thread Adrian Farrel
This is an important piece of work and there are a number of drafts
dependent on it that will provide useful function. So we should
definitely push forward to publication, but we also have to get this
foundational document right otherwise we will struggle later.

I have some moderate-sized issues set out below. Most just need 
editorial work although a couple are more substantive technical points
that may need changes or better explanation.

Thanks for the work.

Adrian

---

I spent a lot of time trying to understand the relationship between
the svec-list and the association group. This understanding was not
enhanced by this document since the mention of svec is actually only
in the RBNF in section 5.2.2. I think the only thing to do to make
this clear is to add a specific section "Relationship with the SVEC
List" and use that to explain how the two constructs relate.

Now, I know that this document doesn't define any Association Types,
and that might mean that you think you don't have to describe the
relationship: "It is up to the documents that define individual
Association Types," you may say. But I think you have to give some
guidance in this document since you are defining a mechanism that is
at last superficially similar. And certainly some (but not all) of
the motivations in 3.1 might be achieved using SVEC.

---

You don't make a lot of mention of RFC 6780. In fact, you only use
it to define the association source. I think you need to describe
how the PCEP Association maps to the RSVP-TE Association at least
at a high level. (Again, I hear you saying that is an issue for
the subsequent documents, but I think you have to give a framework.

---

Why is there a different timeout for association state and LSP state?

You have 

   Association Timeout Interval: when a PCEP session is terminated, a
   PCC waits for this time period before deleting associations created
   by the PCEP peer.

and

   The association are properties of the LSP and thus could be stored in
   the LSP state database.  The dynamic association exist as long as the
   LSP state.  In case of PCEP session termination, the LSP state clean
   up SHOULD also take care of associations.

Section 5.3 is not altogether clear and I suspect some of the procedures
it describes are not defined in this document but are inherited from 
another document. 

---

3.3 has

   A range of association identifier for each association-type are kept
   for the operator-configured associations.  Dynamic associations MUST
   NOT use the association identifier from this range.

What error code is used if a dynamic association breaks this rule? I 
can't see the behavior described.

---

As far as I can see, the only reason you need the Operator-configured
Association Range TLV is because you allow the Association Source to be
set arbitrarily. But there is completely no value in doing that! An
association is created by some element in the system and that element
needs to be clearly identified. Thus the association ID is not globally
unique, but is interpreted in the context of the association source.

Now, when a new association is advertised by a PCEP speaker, it only has
to fill in itself as the source and then it can choose an association ID
freely according to its own configuration an without negotiation with its
peers.

---

Notwithstanding the previous point, I think there is a slew of error 
cases with the Operator-configured Association Range TLV that haven't
described. The start+range for given type could be larger than 
0x. Two ranges may overlap. The range could be zero.

---

5.1

   R (Removal - 1 bit):  when set, the requesting PCE peer requires the
  removal of an LSP from the association group.  This flag is used
  for ASSOCIATION object in PCRpt and PCUpd message, the flag is
  ignored in other PCEP messages.

What does R==0 signify?

---

5.1

   Association type (2-byte): the association type (for example
   protection).  The association type are defined in separate documents.

You should delete this example as you have no firm evidence that there
will be a protection association type. On the other hand, you should
reference section 6.4.

---

5.1

   Association Source: 4 or 16 bytes - An IPv4 or IPv6 address.  This
   could be the IP address of the PCEP speaker that created a dynamic
   association, an operator configured IP address, or an IP address
   selected as per the local policy.  The value such as 0.0.0.0 or
   ::/128 are acceptable.

As per my previous comments, I'm not comfortable with a lot of this.
If you use anything other than a local identifier (for creating an
association) or the identifier used when the association was created
(for modifying an existing association) then you have a recipe for
complete chaos!

It may be that what you want to do here is completely rational, but
the explanation is foggy at best. Perhaps an approach is to describe
this field as:

   Association Source: 4 or 16 bytes - An 

Re: [Pce] WG LC of draft-ietf-pce-association-group

2018-02-02 Thread Hariharan Ananthakrishnan
Support as co-author.

- Hari
On 01/02/2018, 06:10, "Pce on behalf of Julien Meuric"  wrote:

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.

Regards,

Jon & Julien

___
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] WG LC of draft-ietf-pce-association-group

2018-02-01 Thread Qin Wu
Support.

-Qin
-邮件原件-
发件人: Pce [mailto:pce-boun...@ietf.org] 代表 Julien Meuric
发送时间: 2018年2月1日 22:10
收件人: pce@ietf.org
主题: [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.

Regards,

Jon & Julien

___
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] WG LC of draft-ietf-pce-association-group

2018-02-01 Thread Cyril Margaria
Hi,

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.


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)



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?

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

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



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


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


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.



Thanks, Cyril


On 1 February 2018 at 10:38,  wrote:

> Support
>
> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
> Sent: Thursday, February 01, 2018 15:10
> To: 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.
>
> Regards,
>
> Jon & Julien
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
> 
> _
>
> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


Re: [Pce] WG LC of draft-ietf-pce-association-group

2018-02-01 Thread stephane.litkowski
Support

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
Sent: Thursday, February 01, 2018 15:10
To: 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.

Regards,

Jon & Julien

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

_

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@ietf.org
https://www.ietf.org/mailman/listinfo/pce


Re: [Pce] WG LC of draft-ietf-pce-association-group

2018-02-01 Thread Jeff Tantsura
Yes/support

Cheers,
Jeff
On 2/1/18, 09:10, "Pce on behalf of Julien Meuric"  wrote:

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.

Regards,

Jon & Julien

___
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