IS-IS Traffic Engineering (TE) Metric Extensions
draft-ietf-isis-te-metric-extensions-11

[Ballot comment]
Thanks for resolving my DISCUSS points.

Old COMMENT points:

(1) In Section 5:

OLD
Min and max delay MAY be the lowest and/or highest measured value
  over a measurement interval

NEW 
Min and max delay MAY be the lowest and highest measured value
  over a measurement interval, respectively,
 
(2) Section 11 says:

"It is anticipated that in most deployments, IS-IS protocol is used
  within an infrastructure entirely under control of the dame operator."
 
But Section 1 says:

"The data distributed by the IS-IS TE Metric Extensions proposed in
  this document is meant to be used as part of the operation of the
  routing protocol (e.g. by replacing cost with latency or considering
  bandwidth as well as cost), by enhancing Constrained-SPF (CSPF), or
  for other uses such as supplementing the data used by an ALTO server
  [RFC7285]."

In the ALTO case at least it would seem like the point of using this data would be to inform applications (outside the control of the operator) about the cost of routing traffic a certain way. I think this section could be more clear about the expectation that the performance data it exposes may be factored into such costs that get published outside the operator network.

[Ballot comment]


- Couldn't exposing these metrics (e.g. to a passive
attacker) help the attacker decide which part(s) of a network
to attack or help the attacke to measure the effectiveness of
some other attack they have mounted?  (E.g. a physical attack
on fibre) I think that is worth noting in section 11, perhaps
with guidance that sending this information in clear over
less trusted parts of the network might best be avoided, e.g.
by encrypting that traffic? Put another way... I agree with
Alissa's 2nd discuss point, but I'd argue that the proposed
re-phrasing (from mail from Stefano on Feb 2nd) ought include
the above and not only say "might be sensitive."

- Would it be worth noting that if a future specification
allows some control node or router to ask another to emit
these metrics, then that future specification will need to
consider (abuse of) that control interface as a new attack
vector?

[Ballot comment]
From Nevil Brownlee (OPS DIR reviewer) and Stefano Previdi's discussion:

> I have one issue to raise: the last paragraph of section 2
> (introducing the metrics to for each of the new sub-TLVs) says that
> the values "MUST be calculated as rolling averages where the averaging
> period MUST be a configurable period of time."  This draft does not
> say how that interval will be configured.


the paragraph refers to section 5 “Announcement Thresholds and Filters” where the thresholds and average values are explained. The specifics of the configuration are not present because these are implementation specifics aspects.

The same has been done in RFC7471 which is the OSPF version of this draft.


>  For proper operation,
> surely all participating IS-IS routers will need to use the same
> measurement interval?


Well, while it would make sense to use the same interval, it is not a requirement and it’s possible to have a network where nodes use different intervals to measure their links utilization. Also, as described in section 5, the interval may vary and advertisements may be done immediately in some cases.


>  I suggest that some text explaining this, and
> saying how a router's measurement interval can be checked by other
> routers, would be useful.


Here also there are no requirements for a router to be able to verify which interval other routers used.

=====================================

Since that triggered some questions/discussions, a few sentences around the following points would make sense from an OPS point of view:
- While it would make sense to use the same interval, it is not a requirement and it’s possible to have a network where nodes use different intervals to measure their links utilization
- There are no requirements for a router to be able to verify which interval other routers used.

Regards, Benoit

[Ballot comment]
I've only a couple of minor comments to add to what my colleagues have already said:

-- Section 1 --

  For links, such as Forwarding Adjacencies, care must be taken

With the first comma, the qualifier "such as Forwarding Adjacencies" is only parenthetical.  I think you're *specifically* talking about "links such as Forwarding Adjacencies" here, so you need to remove that comma.

-- Section 5 --

  Min and max delay MAY be the lowest and/or highest measured value
  over a measurement interval or MAY make use of a filter, or other
  technique, to obtain a reasonable representation of a min and max
  value representative of the interval with compensation for outliers.

Making sure this normatively says what you want it to:
What this says is that min and max delay can be anything anyone wants it to be, with no restrictions at all, because there are only 2119 "MAY" key words here, and "MAY" means optional.  Specifically, it means that min and max do NOT have to have any resemblance to any reasonable representations.

What I think you *mean* to say is that they each MUST be one of two things: either taken from measured values or be reasonable representations.  You can freely choose between those, but they have to be one or the other.  Is that correct?

If that's correct, then you need to say it in some manner such as this:

NEW
  Min and max delay MUST each be derived in one of the following ways:
  by taking the lowest and/or highest measured value over a measurement
  interval, or by makeins use of a filter or other technique to obtain
  a reasonable representation of a min and max value representative of
  the interval, with compensation for outliers.
END

[Ballot comment]
* The Introduction dismisses queuing delays. However, queue delays pose a large risk to minimizing path delay (and delay variation). How useful is a "minimal delay" path computed by IS-IS if queue delays are not accounted for?

* Does this document use the same definition of delay variation as RFC 3393? There is no clear definition of delay variation provided in this document.

* Section 4.3 states that the "delay variation advertised  by this sub-TLV MUST be the delay from the local neighbor to the remote one." I would assume that "the delay from" is really meant to be "the variation in delay from". Secondly, how does the local (transmitting?) neighbor know the variation in delay? That is typically measured by the receiving neighbor.

[Ballot comment]
* The Introduction hand waves away queuing delays. However, queue delays pose a large risk to minimizing path delay (and delay variation). How useful is a "minimal delay" path computed by IS-IS if queue delays are not accounted for?

* Does this document use the same definition of delay variation as RFC 3393? There is no clear definition of delay variation provided in this document.

* Section 4.3 states that the "delay variation advertised  by this sub-TLV MUST be the delay from the local neighbor to the remote one." I would assume that "the delay from" is really meant to be "the variation in delay from". Secondly, how does the local (transmitting?) neighbor know the variation in delay? That is typically measured by the receiving neighbor.

[Ballot discuss]
(1) There seems to be some inconsistency in the way the A-bit is described as applied to the min/max delay sub-TLV. Section 4.2 says:

"A-bit.  The A-bit represents the Anomalous (A) bit.  The A-bit is set
  when the measured value of this parameter exceeds its configured
  maximum threshold.  The A bit is cleared when the measured value
  falls below its configured reuse threshold.  If the A-bit is clear,
  the sub-TLV represents steady state link performance."

Is the A-bit meant to apply only to the min delay? Or only to the max delay?

Then Section 5 says:

"For sub-TLVs which include an A-bit (except min/max
      delay), an additional threshold SHOULD be included
      corresponding to the threshold for which the performance
      is considered anomalous (and sub-TLVs with the A-bit are
      sent)."

Since min/max delay is excepted from this recommendation, I don't understand what the A-bit means in the min/max delay sub-TLV.

(2) Section 11 says:

"This document does not introduce security issues beyond those
  discussed in [RFC5305]."

This seems false. First, RFC 5305 doesn't seem to discuss any security issues. It points to RFC 5304. But even compared to RFC 5304, it seems this document does introduce new issues, because it exposes real-time performance information about the network which may be commercially sensitive, and which RFC 5305 does not expose. So, for example, the claim in RFC 5304 that "Because a routing protocol contains information that need not be kept secret, privacy is not a requirement," does not seem true. It may be that the same authentication mechanisms can be used, but that doesn't mean the threat model is the same.

Happy to defer to others with more routing security clue than I, but it seems like at a minimum the potential value of the information contained in the new sub-TLVs to an attacker needs to be acknowledged.

[Ballot comment]
(1) In Section 5:

OLD
Min and max delay MAY be the lowest and/or highest measured value
  over a measurement interval

NEW 
Min and max delay MAY be the lowest and highest measured value
  over a measurement interval, respectively,
 
(2) Section 11 says:

"It is anticipated that in most deployments, IS-IS protocol is used
  within an infrastructure entirely under control of the dame operator."
 
But Section 1 says:

"The data distributed by the IS-IS TE Metric Extensions proposed in
  this document is meant to be used as part of the operation of the
  routing protocol (e.g. by replacing cost with latency or considering
  bandwidth as well as cost), by enhancing Constrained-SPF (CSPF), or
  for other uses such as supplementing the data used by an ALTO server
  [RFC7285]."

In the ALTO case at least it would seem like the point of using this data would be to inform applications (outside the control of the operator) about the cost of routing traffic a certain way. I think this section could be more clear about the expectation that the performance data it exposes may be factored into such costs that get published outside the operator network.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-isis-te-metric-extensions-07.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

in the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 subregistry of the IS-IS TLV Codepoints registry located at:

http://www.iana.org/assignments/isis-tlv-codepoints/

The following temporary registrations for values 33, 34, 35, 36, 37, 38 and 39 are to be made permanent and the reference is to be changed to [ RFC-to-be ].

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: isis-chairs@ietf.org, "Hannes Gredler" , draft-ietf-isis-te-metric-extensions@ietf.org, hannes@gredler.at, aretana@cisco.com, isis-wg@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IS-IS Traffic Engineering (TE) Metric Extensions) to Proposed Standard


The IESG has received a request from the IS-IS for IP Internets WG (isis)
to consider the following document:
- 'IS-IS Traffic Engineering (TE) Metric Extensions'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-12-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  In certain networks, such as, but not limited to, financial
  information networks (e.g. stock market data providers), network
  performance criteria (e.g. latency) are becoming as critical to data
  path selection as other metrics.

  This document describes extensions to IS-IS Traffic Engineering
  Extensions (RFC5305) such that network performance information can be
  distributed and collected in a scalable fashion.  The information
  distributed using ISIS TE Metric Extensions can then be used to make
  path selection decisions based on network performance.

  Note that this document only covers the mechanisms with which network
  performance information is distributed.  The mechanisms for measuring
  network performance or acting on that information, once distributed,
  are outside the scope of this document.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-isis-te-metric-extensions/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-isis-te-metric-extensions/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2442/
  https://datatracker.ietf.org/ipr/2109/

AD Review:

Besides the need to shorten the author list and to add more the the Security Considerations section (both identified as Major comments below), the rest are Minor or just Nits.

I am going to start the IETF Last Call, but expect an update to the document to address my comments and any that come up during the LC before the IESG Telechat.

Thanks!

Alvaro.

Major:
(1) There are 7 authors listed on the front page.  In general we want the list to be at most 5.  Please work among yourselves to cut the number of authors.  Alternatively, we can just list an Editor (there's one already identified)..or you can produce a justification detailing the contributions of each author to consider an exception.

(2) Security Considerations.  I'm surprised that there are none.  Some thoughts:
- Instability is a risk.  The text in Sections 5, 6 and 7 aim to reduce the risk, but because everything is configurable the risk is not completely mitigated.  It may be worth calling it out here again.
- Even though the measurement and use of the information is out of scope, the information carried may result in "bad things" if tampered with.  The need for authentication should be called out.

Minor:
(1) In Section 2. (TE Metric Extensions to IS-IS) 
- There are some references missing; for example RFC5311 which is where TLV 23 is defined is not referenced anywhere.
- The second paragraph says that TLVs 22, 141 and 222 have nested sub-TLVs.  This is true for 23 and 223 as well.  It is nice that there are references here, but please be complete.

(2) References:
- I think these references can be made Informative:  RFC3209, RFC4203, RFC6374
- I think we could live without RFC5329

Nits:
(1) In Section 4.7. (Unidirectional Utilized Bandwidth Sub-TLV), the field name is "Bandwidth Utilization" (not Utilized Bandwidth).  All the other sub-TLVs nicely mirror their name to the field name.  Just a nit..

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:

      This document specifies extensions to IS-IS Traffic Engineering
      to include delay, loss, and current bandwidth utilization metric
      that can be taken into account when performing traffic engineering.

Working Group Summary:

      There has been much discusson as to how these metrics would be
      collected and how they will be used. These topics were deemed to
      to be out of scope.

      There was also concern for potential overhead of collecting
      and flooding these metrics. In response, the draft contains
      guidance as to how often the measurements should be collected and
      flooded. Additionally, the draft now recommends configuration
      to control measurement usage and the thresholds for advertisement.

Document Quality:

      This document has been a WG document for a more than two years.
      It is stable, without changes to the technical solution for more
      than 12 months.

Personnel:

      Hannes Gredler is the Document Shepherd.
      Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the IS-IS mailing list.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the review
    that took place.

      No.

(6) Describe any specific concerns or issues that the Document Shepherd
    has with this document that the Responsible Area Director and/or
    the IESG should be aware of? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of BCP
    78 and BCP 79 have already been filed. If not, explain why?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.

      Yes.

      https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-isis-te-metric-extensions

      There wasn't any discussion. IPR on drafts is quite common.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with it?

      There is consensus from the WG and others outside the WG that
      this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(13) Have all references within this document been identified as either
    normative or informative?

      Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their completion?
 
      No.

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document.  Confirm that all protocol extensions that the
    document makes are associated with the appropriate reservations in
    IANA registries. Confirm that any referenced IANA registries have
    been clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been
    suggested (see RFC 5226).
 
      This document defines seven new IS-IS Traffic Engineering sub-TLVs
      that are applicable to the IS-IS 'extended IS-Reach' and
      'multi-topology extended IS-Reach' TLVs.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

      None.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

      Not applicable.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:

      This document specifies extensions to IS-IS Traffic Engineering
      to include delay, loss, and current bandwidth utilization metric
      that can be taken into account when performing traffic engineering.

Working Group Summary:

      There has been much discusson as to how these metrics would be
      collected and how they will be used. These topics were deemed to
      to be out of scope.

      There was also concern for potential overhead of collecting
      and flooding these metrics. In response, the draft contains
      guidance as to how often the measurements should be collected and
      flooded. Additionally, the draft now recommends configuration
      to control measurement usage and the thresholds for advertisement.

Document Quality:

      This document has been a WG document for a more than two years.
      It is stable, without changes to the technical solution for more
      than 12 months.

Personnel:

      Hannes Gredler is the Document Shepherd.
      Alia Atlas is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the IS-IS mailing list.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the review
    that took place.

      No.

(6) Describe any specific concerns or issues that the Document Shepherd
    has with this document that the Responsible Area Director and/or
    the IESG should be aware of? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of BCP
    78 and BCP 79 have already been filed. If not, explain why?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.

      Yes.

      https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-isis-te-metric-extensions

      There wasn't any discussion. IPR on drafts is quite common.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with it?

      There is consensus from the WG and others outside the WG that
      this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(13) Have all references within this document been identified as either
    normative or informative?

      Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their completion?
 
      No.

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document.  Confirm that all protocol extensions that the
    document makes are associated with the appropriate reservations in
    IANA registries. Confirm that any referenced IANA registries have
    been clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been
    suggested (see RFC 5226).
 
      This document defines seven new IS-IS Traffic Engineering sub-TLVs
      that are applicable to the IS-IS 'extended IS-Reach' and
      'multi-topology extended IS-Reach' TLVs.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

      None.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

      Not applicable.