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

From: Julien Meuric <[email-masked]>
Date: Thu, 6 Sep 2018 10:39:32 +0200

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 <[email-masked]>
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&url2=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:
[email-masked]

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.margaria@gmail..com]

Sent: 26 April 2018 00:13

To: Dhruv Dhody <[email-masked]>

Cc: LITKOWSKI Stephane DTF/DERX <[email-masked]>;
Dhruv Dhody <[email-masked]>;
[email-masked]

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 <[email-masked]>
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&url2=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:[email-masked]]
On Behalf Of Cyril
Margaria

Sent: 02 February 2018
04:54

To: LITKOWSKI Stephane
DTF/DERX <[email-masked]>

Cc: [email-masked]

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

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

See 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,

--

[[Dhruv Dhody2]] Ack, updated!

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.

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:

- 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

That is clarified, but as
the global id and extended id are optional, I
understand that   (association
type, association source, association-id)
and (association type, association source,
association-id, extended-id) for example
(10,10,10) and (10,10,10,0) are two
different associations, correct?

[[Dhruv
Dhody2]] Yes, I guess that would be
aligned to RSVP-TE RFC 6780 as well! At
least I think it does!

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!

So that means that the
association information is immutable, a peer
has to delete the association (id is
association-parameters),
then re-create it with same id, new
association information.

I find
this quite restrictive and might cause
churn. For instance the path protection and
diversity group have such information, and
not being able to update them seems too
restrictive (changing  a secondary to
standby for instance)

[[Dhruv
Dhody2]] Our intention was to say that
you could not completely change the
meaning of the association as a whole,
as included in association-information.
You can definitely change the state of
the LSP as a part of an association.. I
will try to reword this.

Also
the I-D where the association types are
defined they could clarify this behavior
as per each association-type use and
encodings.  See updated text.

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.

The processing rules were
expanded greatly,

some new comments:

If a PCEP speaker receives ASSOCIATION in PCReq message, and the

association is not known (association is not configured, or created

dynamically, or learned from a PCEP peer), it MUST return a PCErr

message with Error-Type 26 (Early allocation by IANA) "Association

Error" and Error-Value 4 "Association unknown".

I am confused, that forbids
PCReq on LSP with unknown association. If the
P bit is set, maybe, bit its likely
association-dependent.

[[Dhruv
Dhody2]] Use of a path computation
request message to create a new
association state is not correct for a
message that supposed to be for
stateless PCE model. Ofcourse if PCE is
aware of the association group already
carrying this information as a part of
PCReq is fine!

A
PCReq message on the other hand can
notify PCE of a new association, and PCE
would store the association state as
part of LSP-DB. Does that make sense?

Regards,

Dhruv

Thanks for your patience.

Regards,

Dhruv

Thanks, Cyril

On 1 February
2018 at 10:38, <[email-masked]>
wrote:

Support

-----Original Message-----

From: Pce [mailto:[email-masked]]
On Behalf Of Julien Meuric

Sent: Thursday, February 01,
2018 15:10

To: [email-masked]

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

[email-masked]

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

[email-masked]

https://www.ietf.org/mailman/listinfo/pce

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

---

From: Cyril Margaria <[email-masked]>
Date: Tue, 18 Sep 2018 09:29:49 -0700

Hi,

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

Thanks,
Cyril

On 6 September 2018 at 01:39, Julien Meuric <[email-masked]>
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.
>
> We have posted an update to the association group draft that handle the
> final pending issue regarding capability advertisement.
> Hope the document can be sent to IESG soon!
>
> Thanks!
> Dhruv
>
>> 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&url2=
>> 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&url2=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: [email-masked]
>>
>>
>> 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
>> *From:* Cyril Margaria [mailto:cyril.margaria@gmail..com
>> <[email-masked]>]
>> *Sent:* 26 April 2018 00:13
>> *To:* Dhruv Dhody <[email-masked]>
>> *Cc:* LITKOWSKI Stephane DTF/DERX <[email-masked]>; Dhruv
>> Dhody <[email-masked]>; [email-masked]
>> *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 <[email-masked]> 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&url2=
>> 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&url2=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:[email-masked]] *On Behalf Of *Cyril Margaria
>> *Sent:* 02 February 2018 04:54
>> *To:* LITKOWSKI Stephane DTF/DERX <[email-masked]>
>> *Cc:* [email-masked]
>> *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
>>
>> *[[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! *
>>
>>
>>
>>
>>
>> *[[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:
>>
>>    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:
>>
>>
>>
>>    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.
>>
>>
>>
>> *[[Dhruv Dhody2]] Ack, updated! *
>>
>>
>>
>>
>>
>> section 5.2.1:
>>
>> *[[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. *
>>
>>
>>
>> So
>>
>>
>>
>> *[[Dhruv Dhody]] Ack. *
>> *[[Dhruv Dhody]] Yes*
>> *[[Dhruv Dhody]] I have added a new section on it, also clarified “association information” and “association parameters” in section 5.3*
>>
>>  That is clarified, but as the global id and extended id are optional, I
>> understand that   (association type, association source, association-id)
>> and (association type, association source, association-id, extended-id) for
>> example (10,10,10) and (10,10,10,0) are two different associations, correct?
>>
>>
>>
>> *[[Dhruv Dhody2]] Yes, I guess that would be aligned to RSVP-TE RFC 6780
>> as well! At least I think it does! *
>>
>>
>>
>>
>> *[[Dhruv Dhody]] it is latter, I have updated! *
>>
>>
>>
>> So that means that the association information is immutable, a peer has
>> to delete the association (id is association-parameters), then re-create
>> it with same id, new association information.
>>
>>
>>
>> I find this quite restrictive and might cause churn. For instance the
>> path protection and diversity group have such information, and not being
>> able to update them seems too restrictive (changing  a secondary to standby
>> for instance)
>>
>>
>>
>> *[[Dhruv Dhody2]] Our intention was to say that you could not completely
>> change the meaning of the association as a whole, as included in
>> association-information. You can definitely change the state of the LSP as
>> a part of an association.. I will try to reword this. *
>>
>> *Also the I-D where the association types are defined they could clarify
>> this behavior as per each association-type use and encodings.  See updated
>> text. *
>>
>>
>>
>>
>>
>>
>>
>>
>> *[[Dhruv Dhody]] Please check the diff and let me know if there is scope of any other improvement. *
>>
>>
>>
>> The processing rules were expanded greatly,
>>
>> some new comments:
>>
>>
>>
>> I am confused, that forbids PCReq on LSP with unknown association. If the
>> P bit is set, maybe, bit its likely association-dependent.
>>
>>
>>
>> *[[Dhruv Dhody2]] Use of a path computation request message to create a
>> new association state is not correct for a message that supposed to be for
>> stateless PCE model. Ofcourse if PCE is aware of the association group
>> already carrying this information as a part of PCReq is fine! *
>>
>> *A PCReq message on the other hand can notify PCE of a new association,
>> and PCE would store the association state as part of LSP-DB. Does that make
>> sense? *
>>
>>
>>
>> *Regards,*
>>
>> *Dhruv*
>>
>>
>>
>>
>>
>> *Thanks for your patience. *
>>
>>
>>
>> *Regards,*
>>
>> *Dhruv*
>>
>>
>>
>> Thanks, Cyril
>>
>>
>>
>> On 1 February 2018 at 10:38, <[email-masked]> wrote:
>>
>> Support
>>
>> From: Pce [mailto:[email-masked]] On Behalf Of Julien Meuric
>> Sent: Thursday, February 01, 2018 15:10
>> To: [email-masked]
>> 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
>>
>> ____________________________________________________________
>> _____________________________________________________________
>>
>> 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 [email-masked]://www.ietf.org/mailman/listinfo/pce
>
>
>