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

[Dhruv Dhody <[e-mail]>]

Hi Adrian,

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

From: Pce [mailto:[e-mail]] On Behalf Of Adrian Farrel
Sent: 19 January 2017 01:44
To: 'Jonathan Hardwick' <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]
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

- - - - - -

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.

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

---

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.


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

---

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?

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

(BTW - Having a way for the PCC to report measurements to the PCE
does not necessarily imply using a PCRpt for that purpose.)

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

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


[Dhruv] Ack and Updated.

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.

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

---

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.


[Dhruv] Agree and updated.


---

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.

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

---

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


[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

   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.


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

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

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

[Dhruv] Yes, updated.
---

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


[Dhruv] Ack and Updated.

---

Do you need section 5.7 for PCUpd?


[Dhruv] Added.

---

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.

[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].

---

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?


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

---

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?

[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

"IETF Consensus" is now called "IETF Review". You also need a reference
to RFC 5226.

[Dhruv] Ack.
---

8.3.  AUTO-BANDWIDTH-ATTRIBUTE Sub-TLV

You need to define the allocation policy for this new registry.

[Dhruv] Added

---

The absence of TBD2 and TBD3 is not critical, but cause IANA and the
RFC editor to ask you a question.

[Dhruv] Ack.

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

Regards,
Dhruv


From: Pce [mailto:[e-mail]] On Behalf Of Jonathan Hardwick
Sent: 05 January 2017 15:24
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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