Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
Hi, I think the main point is what does the session reset bring here ? IMO nothing in that case, your session will constantly bounce until the someone reduce the number of states sent by a particular PCC which will create even more load on the PCE. This is an event that cannot be corrected by the session reset. Logging the Notification is a better approach that would allow the operator to be informed and trigger a fix. So I do not think that "MUST terminate" is a good way to go. Brgds, Stephane -Original Message- From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric Sent: Tuesday, May 09, 2017 12:21 To: Dhruv Dhody Cc: pce@ietf.org Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text Hi Dhruv, At this stage, it seems a bit late to introduce this change into the document. However, keeping only "MAY" would allow implementations to behave the way you suggest. Do we consider your feedback as supporting "MAY"? Thanks, Julien May. 09, 2017 - dhruv.dh...@huawei.com: > > Hi Jon, WG, > > > > I feel this was done to differentiate two cases - > > > > (1) The resource limit happened during state synchronization > (section 5.6) - with MUST close session > > (2) The resource limit happened during normal state report - with > MAY close session > > > > We could make this explicit and differentiate the two scenarios? > > > > Regards, > > Dhruv > > > > > > > > *From:*Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Jonathan > Hardwick > *Sent:* 08 May 2017 21:49 > > > > Hi PCE WG > > > > I've been tidying up the stateful PCE draft to prepare it for > publication and I have discovered an inconsistency in how the stateful > PCE is supposed to handle an overflow of its per-PCC resource limit. > In section 5.6 it says: > > > >A PCE implementing a limit on the resources a single PCC can > occupy, > >MUST send a PCNtf message with Notification Type to be allocated by > >IANA (Stateful PCE resource limit exceeded) and Notification Value > to > >be allocated by IANA (Entering resource limit exceeded state) in > >response to the PCRpt message triggering this condition in the > >synchronization phase and MUST terminate the session. > > > > Whereas in section 6.1 it says: > > > >A PCE may choose to implement a limit on the resources a single PCC >can occupy. If a PCRpt is received that causes the PCE to exceed >this limit, the PCE MUST notify the PCC using a PCNtf message with >Notification Type to be allocated by IANA (Stateful PCE resource >limit exceeded) and Notification Value to be allocated by IANA >(Entering resource limit exceeded state) and MAY terminate the >session. > > > > These sections are inconsistent because the first says the PCE MUST > terminate the session whereas the second says the PCE MAY terminate > the session. > > > > Furthermore, in section 8.6, the following notification is defined for > "exiting resource limit exceeded state", but this notification is not > referenced anywhere in the text. > > > > Notification-Type Meaning >4Stateful PCE resource limit exceeded > Notification-value=2: Exiting resource limit exceeded > state > > > > Please could I ask all implementers: > > - MUST the PCE terminate the session if its state limit is > exceeded, or MAY it leave it open? > > - Has anybody implemented the "exiting resource limit > exceeded state" notification? If so, how are you using it? > > > > Your swiftest answers would be very much appreciated! > > > > If I don't get any contradictory replies, my default action will be to > say that the session MUST be terminated and to remove the unreferenced > notification-value. > > > > Many thanks > > Jon > > > > > > ___ > 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 _ 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 att
Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
Ramon, Thanks a lot for your feedback, this is very helpful. Julien May. 09, 2017 - ramon.casel...@cttc.es: > On 9/5/17 12:18, Julien Meuric wrote: >> On the former, we must not forget that: >> - the use of PCNtf is consistent with the overload case in RFC 5440, >> - draft-ietf-pce-stateful-pce passed IESG review (as well as previous WG >> and IETF LCs), >> - draft-ietf-pce-stateful-pce has early allocated codepoints. >> As a result, the PCNtf is not an open question in the current case. > (snip) > > Hi again Julien, > > Thanks for reminding me of the specific question and sorry for diverging > in multiple ways :) In view of your further comments and draft > constraints, my preference remains as follows: > > I still consider not being able to complete sync as a serious error and > I would suggest a MUST close the session, regardless of the actual > message to indicate such failure. > > Thanks > R. > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
Hi Julien, I agree. So "MAY" is the best way forward. Regards, Dhruv > -Original Message- > From: Julien Meuric [mailto:julien.meu...@orange.com] > Sent: 09 May 2017 15:51 > To: Dhruv Dhody > Cc: Jonathan Hardwick ; pce@ietf.org > Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text > > Hi Dhruv, > > At this stage, it seems a bit late to introduce this change into the > document. However, keeping only "MAY" would allow implementations to > behave the way you suggest. Do we consider your feedback as supporting > "MAY"? > > Thanks, > > Julien > > > May. 09, 2017 - dhruv.dh...@huawei.com: > > > > Hi Jon, WG, > > > > > > > > I feel this was done to differentiate two cases - > > > > > > > > (1) The resource limit happened during state synchronization > > (section 5.6) - with MUST close session > > > > (2) The resource limit happened during normal state report - with > > MAY close session > > > > > > > > We could make this explicit and differentiate the two scenarios? > > > > > > > > Regards, > > > > Dhruv > > > > > > > > > > > > > > > > *From:*Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Jonathan > > Hardwick > > *Sent:* 08 May 2017 21:49 > > > > > > > > Hi PCE WG > > > > > > > > I've been tidying up the stateful PCE draft to prepare it for > > publication and I have discovered an inconsistency in how the stateful > > PCE is supposed to handle an overflow of its per-PCC resource limit. > > In section 5.6 it says: > > > > > > > >A PCE implementing a limit on the resources a single PCC can > > occupy, > > > >MUST send a PCNtf message with Notification Type to be allocated by > > > >IANA (Stateful PCE resource limit exceeded) and Notification Value > > to > > > >be allocated by IANA (Entering resource limit exceeded state) in > > > >response to the PCRpt message triggering this condition in the > > > >synchronization phase and MUST terminate the session. > > > > > > > > Whereas in section 6.1 it says: > > > > > > > >A PCE may choose to implement a limit on the resources a single PCC > >can occupy. If a PCRpt is received that causes the PCE to exceed > >this limit, the PCE MUST notify the PCC using a PCNtf message with > >Notification Type to be allocated by IANA (Stateful PCE resource > >limit exceeded) and Notification Value to be allocated by IANA > >(Entering resource limit exceeded state) and MAY terminate the > >session. > > > > > > > > These sections are inconsistent because the first says the PCE MUST > > terminate the session whereas the second says the PCE MAY terminate > > the session. > > > > > > > > Furthermore, in section 8.6, the following notification is defined for > > "exiting resource limit exceeded state", but this notification is not > > referenced anywhere in the text. > > > > > > > > Notification-Type Meaning > >4Stateful PCE resource limit exceeded > > Notification-value=2: Exiting resource limit exceeded > > state > > > > > > > > Please could I ask all implementers: > > > > - MUST the PCE terminate the session if its state limit is > > exceeded, or MAY it leave it open? > > > > - Has anybody implemented the "exiting resource limit > > exceeded state" notification? If so, how are you using it? > > > > > > > > Your swiftest answers would be very much appreciated! > > > > > > > > If I don't get any contradictory replies, my default action will be to > > say that the session MUST be terminated and to remove the unreferenced > > notification-value. > > > > > > > > Many thanks > > > > Jon > > > > > > > > > > > > ___ > > 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] Stateful PCE: inconsistency in "resource limit" text
On 9/5/17 12:18, Julien Meuric wrote: On the former, we must not forget that: - the use of PCNtf is consistent with the overload case in RFC 5440, - draft-ietf-pce-stateful-pce passed IESG review (as well as previous WG and IETF LCs), - draft-ietf-pce-stateful-pce has early allocated codepoints. As a result, the PCNtf is not an open question in the current case. (snip) Hi again Julien, Thanks for reminding me of the specific question and sorry for diverging in multiple ways :) In view of your further comments and draft constraints, my preference remains as follows: I still consider not being able to complete sync as a serious error and I would suggest a MUST close the session, regardless of the actual message to indicate such failure. Thanks R. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
Hi Dhruv, At this stage, it seems a bit late to introduce this change into the document. However, keeping only "MAY" would allow implementations to behave the way you suggest. Do we consider your feedback as supporting "MAY"? Thanks, Julien May. 09, 2017 - dhruv.dh...@huawei.com: > > Hi Jon, WG, > > > > I feel this was done to differentiate two cases – > > > > (1) The resource limit happened during state synchronization > (section 5.6) – with MUST close session > > (2) The resource limit happened during normal state report – with > MAY close session > > > > We could make this explicit and differentiate the two scenarios? > > > > Regards, > > Dhruv > > > > > > > > *From:*Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Jonathan Hardwick > *Sent:* 08 May 2017 21:49 > > > > Hi PCE WG > > > > I’ve been tidying up the stateful PCE draft to prepare it for > publication and I have discovered an inconsistency in how the stateful > PCE is supposed to handle an overflow of its per-PCC resource limit. > In section 5.6 it says: > > > >A PCE implementing a limit on the resources a single PCC can occupy, > >MUST send a PCNtf message with Notification Type to be allocated by > >IANA (Stateful PCE resource limit exceeded) and Notification Value to > >be allocated by IANA (Entering resource limit exceeded state) in > >response to the PCRpt message triggering this condition in the > >synchronization phase and MUST terminate the session. > > > > Whereas in section 6.1 it says: > > > >A PCE may choose to implement a limit on the resources a single PCC >can occupy. If a PCRpt is received that causes the PCE to exceed >this limit, the PCE MUST notify the PCC using a PCNtf message with >Notification Type to be allocated by IANA (Stateful PCE resource >limit exceeded) and Notification Value to be allocated by IANA >(Entering resource limit exceeded state) and MAY terminate the >session. > > > > These sections are inconsistent because the first says the PCE MUST > terminate the session whereas the second says the PCE MAY terminate > the session. > > > > Furthermore, in section 8.6, the following notification is defined for > “exiting resource limit exceeded state”, but this notification is not > referenced anywhere in the text. > > > > Notification-Type Meaning >4Stateful PCE resource limit exceeded > Notification-value=2: Exiting resource limit exceeded > state > > > > Please could I ask all implementers: > > - MUST the PCE terminate the session if its state limit is > exceeded, or MAY it leave it open? > > - Has anybody implemented the “exiting resource limit > exceeded state” notification? If so, how are you using it? > > > > Your swiftest answers would be very much appreciated! > > > > If I don’t get any contradictory replies, my default action will be to > say that the session MUST be terminated and to remove the unreferenced > notification-value. > > > > Many thanks > > Jon > > > > > > ___ > 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] Stateful PCE: inconsistency in "resource limit" text
Hi again Ramon,
We are tackling 2 topics here: the stateful I-D on the table and PCErr
vs. PCNtf at large (see [JM] below).
On the former, we must not forget that:
- the use of PCNtf is consistent with the overload case in RFC 5440,
- draft-ietf-pce-stateful-pce passed IESG review (as well as previous WG
and IETF LCs),
- draft-ietf-pce-stateful-pce has early allocated codepoints.
As a result, the PCNtf is not an open question in the current case.
Then in the text...
May. 09, 2017 - ramon.casel...@cttc.es:
> On 9/5/17 10:35, Julien Meuric wrote:
>> Hi Ramon,
>>
>> Indeed, the I-D used to consider an error for this case, but RFC 5440
>> gives the pace and 2 codepoints were allocated:
>> - PCErr are associated to PCEP issues ("when a protocol error condition
>> is met or when the request is not compliant with the PCEP specification");
>> - PCNtf are typically used for other cases, including PCE state (e.g.
>> overload) and policy (e.g. threshold).
>>
>> Please note also that the current (orphan) text of the I-D allows to use
>> the PCNtf for "Exiting resource limit exceeded state". I am not saying
>> the latter should be kept, but considering this option sustains the idea
>> of having 2 possible messages/behaviors in PCEP.
>
> Hi Julien,
>
> This is indeed making me raise more questions than expected.
>
> - Reading the section I got the feeling that any event preventing to
> reach full sync state caused a PCErr (now PCNtf) and a MUST session
> close. was it the intent?
[JM] Allow me to rephrase a bit: "preventing to reach full sync state
caused an error advertised using a PCNtf". The impact on session closure
is the only discussed topic.
>
> - As a minor comment, I see your point on the PCErr / PCNtf
> "macroscopic use", although I would humbly object, notably in view of
> the whole PCErr 5: policy violation, that includes cases such as
> "global concurrent optimization not allowed" or "objective function
> not allowed" so, while I can agree with your view, IMHO it is not
> black/white.
> In particular, I think you are not fully quoting RFC5440
>
>The PCEP Error message (also referred to as a PCErr message) is sent
>in several situations: when a protocol error condition is met or when
>the request is not compliant with the PCEP specification (e.g.,
>reception of a malformed message, reception of a message with a
>mandatory missing object, policy violation, unexpected message,
>unknown request reference)
>
> It seems to me that policiy violation is a PCErr.
[JM] You are right, it is not black/white. E.g. there are various types
of policy violations:
- operations the PCEP peer is not allowed to do (it may even be aware
before trying);
- live situation changes, like overload or threshold crossing (here, a
PCC is not necessarily misbehaving but hitting a PCE-local value);
- etc.
Generally speaking, I do not see in RFC 5440 a very strict line
splitting between PCErr and PCNtf, the discussion on ties should happen
on a case by case basis. We should at least avoid to decide based on the
message name. The actual question is: does a given feature match the
5/12 message/object kind or the 6/13 one? An opportunity (even if not
specified) to exit a faced situation (like overload or threshold
crossing) may often suggest to consider PCNtf, but this is not a strict
definition.
> However, the main question is:
>
> - Is not reaching full sync considered a protocol error? (for whatever
> reason, and beyond a single message exchange but more as a
> transactional thing/sequence) If yes, I would vote for a PCErr / MUST
> close
>
> - If it is not an error (I am not fully aware of the implications)
> then we should allow PCNtf + MAY leave it open. Otherwise, my view
> remains PCErr + MUST close.
[JM] I do not think message type and session closure are so tied. In the
current document, PCNtf is no more questionable. Consequently, can we
consider your statement as a voice for "MAY" in the document?
Thanks,
Julien
>
> Thanks!
> Ramon
>
>
>
>
>
> ___
> 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] Stateful PCE: inconsistency in "resource limit" text
Hi Jon, WG, I feel this was done to differentiate two cases - (1) The resource limit happened during state synchronization (section 5.6) - with MUST close session (2) The resource limit happened during normal state report - with MAY close session We could make this explicit and differentiate the two scenarios? Regards, Dhruv From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick Sent: 08 May 2017 21:49 To: pce@ietf.org Subject: [Pce] Stateful PCE: inconsistency in "resource limit" text Hi PCE WG I've been tidying up the stateful PCE draft to prepare it for publication and I have discovered an inconsistency in how the stateful PCE is supposed to handle an overflow of its per-PCC resource limit. In section 5.6 it says: A PCE implementing a limit on the resources a single PCC can occupy, MUST send a PCNtf message with Notification Type to be allocated by IANA (Stateful PCE resource limit exceeded) and Notification Value to be allocated by IANA (Entering resource limit exceeded state) in response to the PCRpt message triggering this condition in the synchronization phase and MUST terminate the session. Whereas in section 6.1 it says: A PCE may choose to implement a limit on the resources a single PCC can occupy. If a PCRpt is received that causes the PCE to exceed this limit, the PCE MUST notify the PCC using a PCNtf message with Notification Type to be allocated by IANA (Stateful PCE resource limit exceeded) and Notification Value to be allocated by IANA (Entering resource limit exceeded state) and MAY terminate the session. These sections are inconsistent because the first says the PCE MUST terminate the session whereas the second says the PCE MAY terminate the session. Furthermore, in section 8.6, the following notification is defined for "exiting resource limit exceeded state", but this notification is not referenced anywhere in the text. Notification-Type Meaning 4Stateful PCE resource limit exceeded Notification-value=2: Exiting resource limit exceeded state Please could I ask all implementers: - MUST the PCE terminate the session if its state limit is exceeded, or MAY it leave it open? - Has anybody implemented the "exiting resource limit exceeded state" notification? If so, how are you using it? Your swiftest answers would be very much appreciated! If I don't get any contradictory replies, my default action will be to say that the session MUST be terminated and to remove the unreferenced notification-value. Many thanks Jon ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
On 9/5/17 10:35, Julien Meuric wrote:
Hi Ramon,
Indeed, the I-D used to consider an error for this case, but RFC 5440
gives the pace and 2 codepoints were allocated:
- PCErr are associated to PCEP issues ("when a protocol error condition
is met or when the request is not compliant with the PCEP specification");
- PCNtf are typically used for other cases, including PCE state (e.g.
overload) and policy (e.g. threshold).
Please note also that the current (orphan) text of the I-D allows to use
the PCNtf for "Exiting resource limit exceeded state". I am not saying
the latter should be kept, but considering this option sustains the idea
of having 2 possible messages/behaviors in PCEP.
Hi Julien,
This is indeed making me raise more questions than expected.
- Reading the section I got the feeling that any event preventing to
reach full sync state caused a PCErr (now PCNtf) and a MUST session
close. was it the intent?
- As a minor comment, I see your point on the PCErr / PCNtf "macroscopic
use", although I would humbly object, notably in view of the whole PCErr
5: policy violation, that includes cases such as "global concurrent
optimization not allowed" or "objective function not allowed" so, while
I can agree with your view, IMHO it is not black/white.
In particular, I think you are not fully quoting RFC5440
The PCEP Error message (also referred to as a PCErr message) is sent
in several situations: when a protocol error condition is met or when
the request is not compliant with the PCEP specification (e.g.,
reception of a malformed message, reception of a message with a
mandatory missing object, policy violation, unexpected message,
unknown request reference)
It seems to me that policiy violation is a PCErr. However, the main
question is:
- Is not reaching full sync considered a protocol error? (for whatever
reason, and beyond a single message exchange but more as a transactional
thing/sequence) If yes, I would vote for a PCErr / MUST close
- If it is not an error (I am not fully aware of the implications) then
we should allow PCNtf + MAY leave it open. Otherwise, my view remains
PCErr + MUST close.
Thanks!
Ramon
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
Hi Ramon,
Indeed, the I-D used to consider an error for this case, but RFC 5440
gives the pace and 2 codepoints were allocated:
- PCErr are associated to PCEP issues ("when a protocol error condition
is met or when the request is not compliant with the PCEP specification");
- PCNtf are typically used for other cases, including PCE state (e.g.
overload) and policy (e.g. threshold).
Please note also that the current (orphan) text of the I-D allows to use
the PCNtf for "Exiting resource limit exceeded state". I am not saying
the latter should be kept, but considering this option sustains the idea
of having 2 possible messages/behaviors in PCEP.
Thanks for your feedback,
Julien
May. 08, 2017 - cyril.marga...@gmail.com:
> Hi,
>
> From what I recall, the limit exceeded can refer to the number of
> LSPs, memory, ..etc and the notification was introduced to support the
> same logic as rfc5440 "Overloaded PCE" notification.
>
> To keep that and to support soft/administrative limits, I am in favor
> of MAY terminate the session. If the Peer decides to terminate the
> session, a specific code must be used, otherwise the other peer will
> reconnect and the session will keep flapping.
>
> BR,
> Cyril
>
> On 8 May 2017 at 12:19, Jonathan Hardwick
> > wrote:
>
> Hi PCE WG
>
>
>
> I’ve been tidying up the stateful PCE draft to prepare it for
> publication and I have discovered an inconsistency in how the
> stateful PCE is supposed to handle an overflow of its per-PCC
> resource limit. In section 5.6 it says:
>
>
>
>A PCE implementing a limit on the resources a single PCC can
> occupy,
>
>MUST send a PCNtf message with Notification Type to be allocated by
>
>IANA (Stateful PCE resource limit exceeded) and Notification
> Value to
>
>be allocated by IANA (Entering resource limit exceeded state) in
>
>response to the PCRpt message triggering this condition in the
>
>synchronization phase and MUST terminate the session.
>
>
>
> Whereas in section 6.1 it says:
>
>
>
>A PCE may choose to implement a limit on the resources a single PCC
>
>can occupy. If a PCRpt is received that causes the PCE to exceed
>
>this limit, the PCE MUST notify the PCC using a PCNtf message with
>
>Notification Type to be allocated by IANA (Stateful PCE resource
>
>limit exceeded) and Notification Value to be allocated by IANA
>
>(Entering resource limit exceeded state) and MAY terminate the
>
>session.
>
>
>
> These sections are inconsistent because the first says the PCE
> MUST terminate the session whereas the second says the PCE MAY
> terminate the session.
>
>
>
> Furthermore, in section 8.6, the following notification is defined
> for “exiting resource limit exceeded state”, but this notification
> is not referenced anywhere in the text.
>
>
>
> Notification-Type Meaning
>
>4Stateful PCE resource limit exceeded
>
> Notification-value=2: Exiting resource limit exceeded
>
> state
>
>
>
> Please could I ask all implementers:
>
> -MUST the PCE terminate the session if its state limit is
> exceeded, or MAY it leave it open?
>
> -Has anybody implemented the “exiting resource limit
> exceeded state” notification? If so, how are you using it?
>
>
>
> Your swiftest answers would be very much appreciated!
>
>
>
> If I don’t get any contradictory replies, my default action will
> be to say that the session MUST be terminated and to remove the
> unreferenced notification-value.
>
>
>
> Many thanks
>
> Jon
>
>
>
> ___ 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
