Subject: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09

From: Jonathan Hardwick <[email-masked]>
Date: Thu, 5 Jan 2017 15:24:13 +0000

All,

This is start of a two week poll on making draft-dhody-pce-stateful-pce-auto-bandwidth-09 a PCE working group document.

https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-auto-bandwidth/

Please review the draft and send an email to the list indicating "yes/support" or "no/do not support".  If indicating no, please state your reasons.  If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document.

The poll ends on Thursday January 19.

Thanks,

Jon, JP and Julien

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 6 Jan 2017 14:51:01 +0530

Yes/Support.

Regards,
Dhruv (as co-author)

On Thu, Jan 5, 2017 at 8:54 PM, Jonathan Hardwick <
[email-masked]> wrote:

> Please review the draft and send an email to the list indicating
> “yes/support” or “no/do not support”.  If indicating no, please state your
> reasons.  If yes, please also feel free to provide comments you'd like to
> see addressed once the document is a WG document.
>
>
>

---

From: Udayasree palle <[email-masked]>
Date: Fri, 6 Jan 2017 11:47:19 +0000

Yes/Support.

Regards,
Udayasree

From: Jonathan Hardwick [mailto:[email-masked]]
Sent: 2017年1月5日 20:54
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09

All,

Please review the draft and send an email to the list indicating “yes/support” or “no/do not support”.  If indicating no, please state your reasons.  If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document.

Thanks,

Jon, JP and Julien

---

From: Rakesh Gandhi <[email-masked]>
Date: Fri, 6 Jan 2017 17:25:27 -0500

Hi,

Yes/support (as a co-author).

Thanks,
Rakesh

---

From: Ravi Singh <[email-masked]>
Date: Fri, 6 Jan 2017 22:49:27 +0000

Hi
Yes/support  (co-author).

Regards
Ravi

From: Rakesh Gandhi [mailto:[email-masked]]
Sent: Friday, January 6, 2017 2:25 PM
To: Jonathan Hardwick <[email-masked]>; [email-masked]; Ravi Singh <[email-masked]>; [email-masked]; Dhruv Dhody <[email-masked]>; [email-masked]; Zhangxian (Xian) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09

Hi,

On Thu, Jan 5, 2017 at 10:24 AM, Jonathan Hardwick <[email-masked]<mailto:[email-masked]>> wrote:

All,

Thanks,

Jon, JP and Julien

---

From: Sureshbr <[email-masked]>
Date: Tue, 10 Jan 2017 07:06:14 +0000

Yes/Support

From: Pce [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: 06 January 2017 17:21
To: Jonathan Hardwick
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09

Yes/Support.

Regards,
Dhruv (as co-author)

On Thu, Jan 5, 2017 at 8:54 PM, Jonathan Hardwick <[email-masked]<mailto:[email-masked]>> wrote:

All,

Thanks,

Jon, JP and Julien

---

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 10 Jan 2017 15:04:08 +0000

Yes/Support.

Thanks,
Himanshu

From: Pce [mailto:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: Thursday, January 05, 2017 10:24 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09

All,

Thanks,

Jon, JP and Julien

---

From: Leeyoung <[email-masked]>
Date: Tue, 10 Jan 2017 16:40:23 +0000

Yes/Support,

Young

From: Pce [mailto:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: Thursday, January 05, 2017 9:24 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09

All,

Thanks,

Jon, JP and Julien

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 10 Jan 2017 10:26:19 -0800

Yes/support

Cheers,

Jeff

All,

Thanks,

Jon, JP and Julien

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 11 Jan 2017 09:07:51 +0000

Yes/support

Daniele

From: Pce [mailto:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: Thursday, January 05, 2017 9:24 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09

All,

Thanks,

Jon, JP and Julien

---

From: Zhenghaomian <[email-masked]>
Date: Wed, 11 Jan 2017 09:11:14 +0000

Yes/Support.

Best wishes,
Haomian

发件人: Pce [mailto:[email-masked]] 代表 Jonathan Hardwick
发送时间: 2017年1月5日 23:24
收件人: [email-masked]
抄送: [email-masked]; [email-masked]
主题: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09

All,

Thanks,

Jon, JP and Julien

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 18 Jan 2017 20:14:21 -0000

Hi Jon, chairs,
 
I think this is something we should be working on and I think that this draft
will be a reasonable starting point although I do have some issues for
discussion.  I think we can handle the issues at any time (including after
adoption).
 
Thanks,
Adrian
 
- - - - - -
 
It might be nice if the Abstract gave a very simple explanation of  
"automatic bandwidth adjustment". You have text in the Introduction 
you could use.
 
---
 
There are three bullets at the end of Section 1, but I lack the context
to understand whether this is a list of possible approaches, a list of
steps, or something else.
 
---
 
I note that this revision seems to have dropped the ability for a PCC
to report samples to the PCE and have the PCE do all of the work of
determining whether auth-bandwidth adjustments are needed/desirable
before performing the various path computations.
 
There is a clear benefit in pushing the responsibility for deciding when
adjustments are needed to the PCC. This distributes the load of 
monitoring the LSPs down to the PCCs and frees up the PCE as well as 
reducing the load on PCEP communications. However, ...
 
Exactly when to adjust an LSP (and the scaling consequences discussed in
4.3) could be better left to a PCE. That is, a PCE could be flexible in
its interpretation of thresholds enabling it to trigger adjustment early
if it believes there is a good reason (for example, doing a set of
parallel recomputations) or late (for example, when it knows that an 
adjustment would be disruptive to the network and can see the changes
that lead to an adjustment request). When this is delegated to the PCC,
the PCC cannot see the impact on other LSPs, and the PCE cannot tell
whether the request for adjust the LSP is critical or moderate.
 
Clearly there are options and trade-offs, and different pain points.
Was there a logic to this edit?
 
(BTW - Having a way for the PCC to report measurements to the PCE
does not necessarily imply using a PCRpt for that purpose.)
 
Note that in 4.2 you have
   The PCEP
   peer which is in-charge of calculating the bandwidth to be adjusted,
   will adjust the bandwidth of the LSP to the highest sampled traffic
   rate (MaxAvgBw) amongst the set of bandwidth samples collected over
   the adjustment-interval.
I think that *in*your*current*revision* "The PCEP peer" means "the PCC"
and that "the PCC" is congruent to the "LSP head end".
 
Similarly, when you took text out in this revision, I think you missed
updating 4.3 where you have...
   If a PCE gets overwhelmed, it can notify the PCC to temporarily
   suspend its auto-bandwidth reporting (see Section 5.6).
...yet the PCC does not (now) do auto-bandwidth reporting.
 
---
 
I think the table in Section 3 slightly misses the point. The statement
"No new extensions are needed" is currently applied to "PCC Initiated",
but I think there may be confusion in the delegated case. That is, once
delegated, a PCC *could* send a request for adjustment, but neither the
PCC nor the PCE may really be expecting that. They may expect something
more similar to the PCE-initiated case. Thus, at the time of delegation,
the PCE needs to be able to say "yes, delegated, but I want you to 
monitor the LSP with these parameters." Maybe, also, at the time of
delegation the PCC should be letting the PCE know what monitoring it is
planning on doing.
 
---
 
4.1 has...
   Auto-Bandwidth feature allows an LSP to automatically and dynamically
   adjust its reserved bandwidth over time, i.e. without network
   operator intervention.
Well, of course, the LSP does no such thing. Probably the head-end LSR
does that.
 
---
 
Did you consider allowing a different Adjustment-Interval for adjustment
up and adjustment down (with them defaulting to the same value)?
 
---
 
4.2 has
 
   All thresholds in this document could be represented in both absolute
   value and percentage, and could be used together.
 
I looked but couldn't find. If absolute and percentage are both supplied
and imply different thresholds, which one is used? Could be as simple as
"the first threshold hit", but this could lead to some flaps that are 
not obvious to someone staring at either the up/down percentage 
thresholds or at the up/down absolute values.
 
---
 
5.2 has
   For PCE-Initiated LSP ([I-D.ietf-pce-pce-initiated-lsp]), this TLV is
   included in the LSPA Object with PCInitiate message.  For delegated
   LSPs, this TLV is carried in PCRpt message in LSPA Object.    
I *think* that a PCUpd can also carry these to allow a PCE to direct the
PCC to use different parameters with the LSP.
 
---
 
5.2
   The TLV is encoded in all PCEP messages for the LSP till the auto
   bandwidth adjustment feature is enabled, the absence of the TLV
   indicate the PCEP speaker wish to disable the feature.   
Does this mean
   The TLV is encoded in all PCEP messages for the LSP while the auto
   bandwidth adjustment feature is enabled, the absence of the TLV
   indicate the PCEP speaker wish to disable the feature.   
??
 
---
 
5.2
   Length: Variable
How true!
But what does it encode?
 
---
 
Do you need section 5.7 for PCUpd?
 
---
 
You have...
  This document defines AUTO-BANDWIDTH-CAPABILITY TLV,
   AUTO-BANDWIDTH-ATTRIBUTE TLV which do not add any new security
   concerns beyond those discussed in [RFC5440] and
   [I-D.ietf-pce-stateful-pce].
 
   Some deployments may find the reporting of the auto-bandwidth
   information as extra sensitive and thus SHOULD employ suitable PCEP
   security mechanisms like TCP-AO or [I-D.ietf-pce-pceps].
 
Are you sure there are no additional security concerns as stated in 
your first paragraph. Doesn't your second paragraph say that there
*are* additional concerns: in particular that things be deduced from the
fact of, the timing of, and the amount of adjustments? So even if the 
messages are protected from spoofing or modification, that wouldn't be
enough.
 
---
 
7.2.  Information and Data Models
 
   [RFC7420] describes the PCEP MIB, there are no new MIB Objects
   defined in this document.
 
What you say is true. But do you think there is a need for an 
augmentation for the new features?
 
What about YANG?
 
---
 
7.6.  Impact On Network Operations
 
   Mechanisms defined in this document do not have any impact on network
   operations in addition to those already listed in [RFC5440].
 
Really?
Haven't you described a mechanism specifically designed to change the
way that the network is operated? Haven't you also described problems 
(and mitigations) that could cause PCC and PCE to be swamped?
 
---
 
8.2
 
"IETF Consensus" is now called "IETF Review". You also need a reference
to RFC 5226.
 
---
 
8.3.  AUTO-BANDWIDTH-ATTRIBUTE Sub-TLV
 
You need to define the allocation policy for this new registry.
 
---
 
The absence of TBD2 and TBD3 is not critical, but cause IANA and the
RFC editor to ask you a question.

From: Pce [mailto:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: 05 January 2017 15:24
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09
 
All,
 
This is start of a two week poll on making
draft-dhody-pce-stateful-pce-auto-bandwidth-09 a PCE working group document.
https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-auto-bandwidth/
 
Please review the draft and send an email to the list indicating "yes/support"
or "no/do not support".  If indicating no, please state your reasons.  If yes,
please also feel free to provide comments you'd like to see addressed once the
document is a WG document.

Thanks,
Jon, JP and Julien

---

From: Jonathan Hardwick <[email-masked]>
Date: Fri, 20 Jan 2017 08:45:51 +0000

Thanks all for your replies.  This WG adoption poll has ended, with the result that the document will be adopted by the PCE working group.

Authors, please resubmit this document as draft-ietf-pce-stateful-pce-auto-bandwidth-00 (with no other changes).  As there were some comments during WG adoption, please address those comments and post any necessary updates in a version -01.

Best regards
Jon

All,

Thanks,

Jon, JP and Julien

---

From: Dhruv Dhody <[email-masked]>
Date: Sat, 28 Jan 2017 07:54:36 +0000

Hi Adrian,

Thanks for your support and comments. Apologies for the delay in the reply. See inline...

From: Pce [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 19 January 2017 01:44
To: 'Jonathan Hardwick' <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09

Hi Jon, chairs,

I think this is something we should be working on and I think that this draft will be a reasonable starting point although I do have some issues for discussion.  I think we can handle the issues at any time (including after adoption).

Thanks,
Adrian

- - - - - -

[Dhruv]  Done!

Automatic bandwidth adjustment allows automatic and dynamic
adjustment of the reserved bandwidth allocation of an TE LSP based on
the volume of traffic flowing through it.

---

[Dhruv] I reworded the text and converted into a paragraph.

The PCC (head-end of the LSP) monitors the traffic flowing through
the LSP and calculates the new adjusted bandwidth.  The PCC reports
the calculated bandwidth to be adjusted to the PCE. This is similar
to a passive stateful PCE model, while the passive stateful PCE uses
path request/reply mechanism, the active stateful PCE uses
report/update mechanism to adjust the LSP bandwidth. In case of PCE-
initiated LSP, the PCC is requested during the LSP initiation to
monitor and calculate the new adjusted bandwidth.

---

[Dhruv] You are right, we have not dropped the model, only decided to pursue the second model in a different draft "draft-gandhi-pce-pm-04" which deals with reporting parameters to the PCE including bandwidth Utilizations, as well as delay, jitter etc. This would be in-line with other RFCs in OSPF, IS-IS and PCE which deals with these parameters together.

[Dhruv] That is true.
In this draft we are focusing on changes in PCEP. If PCE is using some other mechanism to learn, it can still use the existing PCUpd mechanism to update the bandwidth.

[Dhruv] Ack and Updated.

[Dhruv] It is updated to "reporting of the new bandwidth to be adjusted" to be clear.

---

[Dhruv] Agree and updated.

---

4.1 has...

[Dhruv] Ack. Updated to -

Auto-Bandwidth feature allows automatic and dynamic adjustment of the
reserved bandwidth of an LSP over time, i.e. without network operator
intervention.

---

[Dhruv] No, it is not supported by most of the vendors. They keep the same interval but allow setting of different values for the overflow and underflow threshold/count. Do you feel that this should be added?

---

4.2 has

[Dhruv] In section 5.2.3 (and similarly 5.2.5) states -

An implementation MAY include both
sub-TLVs for the absolute value and the percentage, in which case the
bandwidth is adjusted when either of the adjustment threshold
  conditions are met.

Which is similar to what you state.
Do you suggest we add some guidelines to provide information on which threshold is met by logging?
Or do you feel strongly about this and we should use only one format?

---

5.2 has

[Dhruv] Yes that should be clarified. I have added text. This was earlier mentioned further down in the same section.
---

5.2

[Dhruv] Yes, updated.
---

5.2
   Length: Variable
How true!
But what does it encode?

[Dhruv] Ack and Updated.

---

[Dhruv] Added.

---

You have...

[Dhruv] You are right, updated.

This document defines AUTO-BANDWIDTH-CAPABILITY TLV,
   AUTO-BANDWIDTH-ATTRIBUTE TLV which does not add any new security
   concerns beyond those discussed in [RFC5440] and
   [I-D.ietf-pce-stateful-pce] in itself. Some deployments may find the
   auto-bandwidth information as extra sensitive and could be used to
   influence path computation and setup with adverse effect.
   Additionally snooping of PCEP messages with such data or using PCEP
   messages for network reconnaissance, may give an attacker sensitive
   information about the operations of the network. Thus, such
   deployment should employ suitable PCEP security mechanisms like TCP
    Authentication Option (TCP-AO) [RFC5925] or [I-D.ietf-pce-pceps].

---

What about YANG?

[Dhruv] Updated.

A Management Information Base (MIB) module for modeling PCEP is
   described in [RFC7420]. However, the preferred mechanism for
   configuration is through a YANG model [I-D.ietf-pce-pcep-yang]. This
   SHOULD be enhanced to provide controls and indicators for support of
   auto-bandwidth feature. Support for various configuration knobs as
   well as counters of messages sent/received containing the TLVs
   (defined in this document) should be added.

---

Really?

[Dhruv] Updated.

In order to avoid any unacceptable impact on network operations, an
   implementation SHOULD allow a limit to be placed on the number of
   LSPs that can be enabled with auto-bandwidth feature, and MAY allow a
   limit to be placed on the rate of messages sent by a PCEP speaker and
   received from a peer related to auto-bandwidth. It MAY also allow
   sending a notification when the PCEP speaker is overwhelmed or a rate
    threshold is reached.
---

8.2

[Dhruv] Ack.
---

[Dhruv] Added

---

[Dhruv] Ack.

Thanks again for your detailed review. I am attaching a diff.

Regards,
Dhruv

All,

Thanks,

Jon, JP and Julien

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 28 Jan 2017 17:04:35 -0000

Hey Dhruv,

Thanks for the careful response.

I've snipped down to  couple of points.

Best,
Adrian

>> before performing the various path computations.

[snip]

> [Dhruv] You are right, we have not dropped the model, only decided to pursue
> the second model in a different draft “draft-gandhi-pce-pm-04” which deals
> with reporting parameters to the PCE including bandwidth Utilizations, as well
> as delay, jitter etc. This would be in-line with other RFCs in OSPF, IS-IS and
PCE
> which deals with these parameters together.  

OK. Understood. Maybe a simple note and pointer to the other I-D (Informative
reference) would be helpful and stop future reviewers asking similar questions.

> [Dhruv] No, it is not supported by most of the vendors.

ROFL
It's not even a WG draft yet.

> They keep the same interval but allow setting of different values for the
> overflow and underflow threshold/count. Do you feel that this should
> be added? 

Not sure. If I was writing the code, I would certainly have used two different
timers because that is cheap and easy and flexible. Whether I would have exposed
both as configurable in the first release is debatable.

If I was deploying I think I would want to experiment with making changes more
sticky in one direction than in the other direction. How important that is might
depend on how expensive it is to increase b/w once it has been reduced, and how
likely it is that an increase might fail.

> [Dhruv] In section 5.2.3 (and similarly 5.2.5) states – 
>

I think that this may be flexibility too far. I can't see a way that this would
break anything, but might lead to "unexpected" results. For example...

Up % = 1%
Down % = 10%
Up absolute = 1 GB
Down absolute = 1 MB

This would cause wibbles, but maybe that is what the operator has asked for.

But maybe nothing more to say.

---

From: Dhruv Dhody <[email-masked]>
Date: Sun, 29 Jan 2017 16:16:33 +0000

Hi Adrian, 

Thanks for your further response. I have uploaded a new version with two issues open. 
Please see inline. 

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: 28 January 2017 22:35
> To: Dhruv Dhody <[email-masked]>; 'Jonathan Hardwick'
> <[email-masked]>; [email-masked]
> Cc: [email-masked];
> [email-masked]
> Subject: RE: [Pce] Poll for adoption:
> draft-dhody-pce-stateful-pce-auto-bandwidth-09
> 
> Hey Dhruv,
> 
> > [Dhruv] You are right, we have not dropped the model, only decided to
> > pursue the second model in a different draft "draft-gandhi-pce-pm-04"
> > which deals with reporting parameters to the PCE including bandwidth
> > Utilizations, as well as delay, jitter etc. This would be in-line with
> > other RFCs in OSPF, IS-IS and
> PCE

[Dhruv] Done! 

> >> ---
> >> Did you consider allowing a different Adjustment-Interval for
> >> adjustment up and adjustment down (with them defaulting to the same value)?
> >

[Dhruv] :) I meant, for the existing implementation of auto-bandwidth feature with local CSPF. Anyways...  

> > They keep the same interval but allow setting of different values for
> > the overflow and underflow threshold/count. Do you feel that this
> > should be added?
> 
> timers because that is cheap and easy and flexible. Whether I would have
> exposed both as configurable in the first release is debatable.
> 
> If I was deploying I think I would want to experiment with making changes
> more sticky in one direction than in the other direction. How important that
> is might depend on how expensive it is to increase b/w once it has been reduced,
> and how likely it is that an increase might fail.
> 

[Dhruv] Understood. I will keep this point open in the current version and gather feedback from my co-authors as well as operators, before updating.  

> >> I looked but couldn't find. If absolute and percentage are both
> >> supplied and imply different thresholds, which one is used? Could be
> >> as simple as "the first threshold hit", but this could lead to some
> >> flaps that are not obvious to someone staring at either the up/down
> >> percentage thresholds or at the up/down absolute values.
> >
> I think that this may be flexibility too far. I can't see a way that this
> would break anything, but might lead to "unexpected" results. For example...
> 
> Up % = 1%
> Down % = 10%
> Up absolute = 1 GB
> Down absolute = 1 MB
> 

[Dhruv] Personally I am fine either way. I will update once I get a confirmation from my co-authors. 

Thanks again for your reviews. 

Regards,
Dhruv