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

["Adrian Farrel" <[e-mail]>]

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:[e-mail]] On Behalf Of Jonathan Hardwick
Sent: 05 January 2017 15:24
To: [e-mail]
Cc: [e-mail]; [e-mail]
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.
 
The poll ends on Thursday January 19.
 
Thanks,
Jon, JP and Julien