Skip to main content

OSPF Traffic Engineering (TE) Metric Extensions
draft-ietf-ospf-te-metric-extensions-11

Revision differences

Document history

Date Rev. By Action
2015-03-02
11 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-02-25
11 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-02-17
11 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-01-14
11 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2015-01-13
11 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2015-01-12
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2015-01-12
11 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-01-12
11 (System) RFC Editor state changed to EDIT
2015-01-12
11 (System) Announcement was received by RFC Editor
2015-01-12
11 (System) IANA Action state changed to In Progress
2015-01-12
11 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2015-01-12
11 Amy Vezza IESG has approved the document
2015-01-12
11 Amy Vezza Closed "Approve" ballot
2015-01-12
11 Adrian Farrel IESG state changed to Approved-announcement to be sent from Approved-announcement sent
2015-01-12
11 Adrian Farrel IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed
2015-01-12
11 Adrian Farrel Ballot writeup was changed
2015-01-12
11 Adrian Farrel Ballot approval text was generated
2015-01-09
11 John Drake IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2015-01-09
11 John Drake New version available: draft-ietf-ospf-te-metric-extensions-11.txt
2015-01-08
10 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Ólafur Guðmundsson.
2015-01-08
10 Cindy Morgan IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2015-01-08
10 Benoît Claise
[Ballot comment]
From an OPS point of view, I'm mainly interested in what is out of scope, as written in the writeup: "There has been …
[Ballot comment]
From an OPS point of view, I'm mainly interested in what is out of scope, as written in the writeup: "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".
So I'll wait for a companion document.

I agree with Alissa and Stephen that the following paragraph is confusing:

  "While this document does not specify how the performance information
  should be obtained, the measurement of delay SHOULD NOT vary
  significantly based upon the offered traffic load.  Thus, queuing
  delays and/or loss SHOULD NOT be included in any dynamic delay
  measurement."
2015-01-08
10 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2015-01-07
10 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2015-01-07
10 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2015-01-07
10 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2015-01-07
10 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2015-01-07
10 Alia Atlas [Ballot Position Update] New position, Recuse, has been recorded for Alia Atlas
2015-01-07
10 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2015-01-07
10 Jari Arkko
[Ballot comment]
Thank you for doing this work. It is very important and I can clearly see the use cases.

I do have some comments …
[Ballot comment]
Thank you for doing this work. It is very important and I can clearly see the use cases.

I do have some comments though.

I think it would be useful to specify explicitly what the IEEE floating point number format variant is being used. I assume binary32. (Also noted in the Gen-ART review.)

I am a bit surprised by the A bit design. Would it be useful to add some rationale for why this approach has been taken? As I read the document I find it difficult to understand why the bit carries extra value for the receiver. It does signal an exceptional condition, but at the same time, any real action (e.g., Step B in Section 3) seems to be something that should be based on the calculation of the actual bandwidths and delays rather than the flag itself. Or did I misunderstand this?

Also, it would be useful to specify what information must be understood in the network for the A bit usage. Do all nodes have to the same understanding of the threshold throughout the network? Or just the sending node?

Finally, I would have preferred to see some defaults for the various configurable values, and some discussion of the requirements for the values. Again, do the measurement period for instance have to be aligned across a network, or not? A section on management considerations might be appropriate.
2015-01-07
10 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-01-06
10 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2015-01-06
10 Alissa Cooper
[Ballot comment]
= Section 1 =

"While this document does not specify how the performance information
  should be obtained, the measurement of delay SHOULD …
[Ballot comment]
= Section 1 =

"While this document does not specify how the performance information
  should be obtained, the measurement of delay SHOULD NOT vary
  significantly based upon the offered traffic load.  Thus, queuing
  delays and/or loss SHOULD NOT be included in any dynamic delay
  measurement."

Agree with Stephen's comment here -- this is confusing. I'm not sure normative language makes a whole lot of sense here at all if "the measurement" means "the quantity you actually measure" as opposed to "the quantity that you report after measuring."

Also, how would loss be reported in a delay measurement? (I can imagine ways, but they seem contrived.)

= Section 4.2.7 =

"Implementations MAY also permit the configuration of an offset value
  (in microseconds) to be added to the measured delay value to
  advertise operator specific delay constraints."

Do I understand correctly that there is no way specified to communicate this offset value? If this is a matter for local configuration, it seems a bit odd to use normative language and describe it in the definition of the sub-TLV.

= Section 4.4.5 =

"When set to a value of all 1s (2^24 - 1), the link packet loss has
  not been measured."

I noted that in the case of delay, the way to signal that delay has not been measured is to not send or withdraw the sub-TLV, whereas for loss it is to send a specific value. Why do this differently for different measurements?

= Section 7 =

I agree with Barry's comments here.
2015-01-06
10 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2015-01-06
10 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2015-01-06
10 Brian Haberman
[Ballot comment]
I agree with Stephen that the specified use cases seem to warrant a stronger recommendation to provide authentication and confidentiality.  The tools are …
[Ballot comment]
I agree with Stephen that the specified use cases seem to warrant a stronger recommendation to provide authentication and confidentiality.  The tools are available, so why are they not being recommended in this instance?
2015-01-06
10 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2015-01-05
10 Stephen Farrell
[Ballot comment]

These are mainly nits or questions, other than the
first.  That would have been a discuss if I knew of a
specific threat, …
[Ballot comment]

These are mainly nits or questions, other than the
first.  That would have been a discuss if I knew of a
specific threat, but since this is just a general
concern, it's not a discuss. I'd appreciate a bit of
a chat about it though.

- I'd have thought that these TLVs would be sent more
often than others, and that (if enormous amounts of
money are in play) then use of OSPF authentication might
be more likely needed (or some equivalent security
mechanisms). I'd even speculate that if enormous amounts
of money are in play, then confidentiality may become a
requirement (since if I can observe say A bit settings
then that might give me insight into traffic levels -
sort of a lights burning at night in central bank
implies interest-rate change attack). Can you say why
none of that needs to be mentioned at all? Was any of
that considered by the WG? (Can you send a relevant link
to the archive?)

- intro: "extremely large amounts of money" aren't
usually explicit motivations for protocol features and I
hope that that continues to be the case. I'd encourage
you to remove that phrase. Similarly, "faster" is a fine
requirement but "fast than the competition" is not, so a
bit more wordsmithing might be good. (Those are, I
think, defensible points as we ought not over-specialise
our requirements, but to be honest I'd also be happier
if protocol development was not explicitly motivated
soley by increasing already-enormous amounts of money.)

- intro: saying the "measurement of delay SHOULD NOT
vary significantly based upon the offered traffic load"
is odd. Clearly the delay experienced can vary based on
the load, so I'm not sure what you're saying. And nor is
it clear why this is a SHOULD NOT, as opposed to a MUST
NOT. Maybe you need to explain that some more?

- section 3: Doesn't the A bit definition assume that
both senders and receivers know the thresholds (or
enough about those). That seems a bit odd to me, but I
expect you've thought it through.  Same thing with the
averaging period I guess (though section 7 does specify
a 30s default as a SHOULD). Or am I missing that one
could calculate those from the various TLVs that are
defined?  (I think I'm also not understanding bullet
point 4 in section 5 which may be related.)

- section 3: I don't get what "cannot be used for
fail-over purposes" means. I think you mean "ought not"
since a receiver can do what they want in any case.

- The security considerations of RFC 3630, from 2003, is
11 lines long. Has nothing affected OSPF security in the
last decade+ that would be worth noting here?

- In one response to the secdir review, [1] path
shortening attacks were mentioned - I'm not clear myself
if that's a deal here, but is text on that needed? Some
text that was suggested is

"users of the lsas described in this document should be aware of how
they might be used in path shortening and other routing attacks."

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05354.html
2015-01-05
10 Stephen Farrell Ballot comment text updated for Stephen Farrell
2015-01-05
10 John Drake IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2015-01-05
10 John Drake New version available: draft-ietf-ospf-te-metric-extensions-10.txt
2015-01-04
09 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Menachem Dodge.
2015-01-03
09 Stephen Farrell
[Ballot comment]

These are mainly nits or questions, other than the
first.  That would have been a discuss if I knew of a
specific threat, …
[Ballot comment]

These are mainly nits or questions, other than the
first.  That would have been a discuss if I knew of a
specific threat, but since this is just a general
concern, it's not a discuss. I'd appreciate a bit of
a chat about it though.

- I'd have thought that these TLVs would be sent more
often than others, and that (if enormous amounts of
money are in play) then use of OSPF authentication might
be more likely needed (or some equivalent security
mechanisms). I'd even speculate that if enormous amounts
of money are in play, then confidentiality may become a
requirement (since if I can observe say A bit settings
then that might give me insight into traffic levels -
sort of a lights burning at night in central bank
implies interest-rate change attack). Can you say why
none of that needs to be mentioned at all? Was any of
that considered by the WG? (Can you send a relevant link
to the archive?)

- intro: "extremely large amounts of money" aren't
usually explicit motivations for protocol features and I
hope that that continues to be the case. I'd encourage
you to remove that phrase. Similarly, "faster" is a fine
requirement but "fast than the competition" is not, so a
bit more wordsmithing might be good. (Those are, I
think, defensible points as we ought not over-specialise
our requirements, but to be honest I'd also be happier
if protocol development was not explicitly motivated
soley by increasing already-enormous amounts of money.)

- intro: saying the "measurement of delay SHOULD NOT
vary significantly based upon the offered traffic load"
is odd. Clearly the delay experienced can vary based on
the load, so I'm not sure what you're saying. And nor is
it clear why this is a SHOULD NOT, as opposed to a MUST
NOT. Maybe you need to explain that some more?

- section 3: Doesn't the A bit definition assume that
both senders and receivers know the thresholds (or
enough about those). That seems a bit odd to me, but I
expect you've thought it through.  Same thing with the
averaging period I guess (though section 7 does specify
a 30s default as a SHOULD). Or am I missing that one
could calculate those from the various TLVs that are
defined?  (I think I'm also not understanding bullet
point 4 in section 5 which may be related.)

- section 3: I don't get what "cannot be used for
fail-over purposes" means. I think you mean "ought not"
since a receiver can do what they want in any case.

- The security considerations of RFC 3630, from 2003, is
11 lines long. Has nothing affected OSPF security in the
last decade+ that would be worth noting here?

- In one response to the secdir review, [1] path
shortening attacks were mentioned - I'm not clear myself
if that's a deal here, but is text on that needed?

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05354.html
2015-01-03
09 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2015-01-02
09 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2014-12-30
09 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2014-12-29
09 Martin Thomson Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Martin Thomson.
2014-12-29
09 Jean Mahoney Request for Telechat review by GENART is assigned to Martin Thomson
2014-12-29
09 Jean Mahoney Request for Telechat review by GENART is assigned to Martin Thomson
2014-12-29
09 Barry Leiba
[Ballot comment]
A couple of minor, non-blocking comments, just looking for a little clarification:

-- Section 7 --

I can't imagine that the "SHOULD" in …
[Ballot comment]
A couple of minor, non-blocking comments, just looking for a little clarification:

-- Section 7 --

I can't imagine that the "SHOULD" in the first paragraph is an appropriate 2119 key word: no one can tell whether or not care was taken, so this can't be a protocol issue.  Please just say "Therefore it is important to set these values carefully."

For the remaining "SHOULD"s, "SHOULD NOT", and "RECOMMENDED" in this section: remembering that "SHOULD" means that "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course," how can someone reading this understand and weigh those implications?  I can't: I have no idea why these recommendations are being made, and what the implications are of making different choices.  Can you help me here?  Or are these just recommended values, in the lower-case, plain English sense?
2014-12-29
09 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2014-12-28
09 Adrian Farrel IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2014-12-28
09 Adrian Farrel Ballot has been issued
2014-12-28
09 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2014-12-28
09 Adrian Farrel Created "Approve" ballot
2014-12-28
09 Adrian Farrel Placed on agenda for telechat - 2015-01-08
2014-12-28
09 Adrian Farrel Changed consensus to Yes from Unknown
2014-12-27
09 John Drake IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-12-27
09 John Drake New version available: draft-ietf-ospf-te-metric-extensions-09.txt
2014-12-24
08 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2014-12-17
08 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2014-12-17
08 Amanda Baber
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ospf-te-metric-extensions-08.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ospf-te-metric-extensions-08.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that upon approval of this document, there is a single action which needs to be completed.

In the Types for sub-TLVs of TE Link TLV (Value 2) sub-registry of the Open Shortest Path First (OSPF) Traffic Engineering TLVs registry located at:

https://www.iana.org/assignments/ospf-traffic-eng-tlvs/

seven new type codes per sub-TLV will be defined as follows:

Type: [ TDB-at-registration ]
Description: Unidirectional Link Delay
Reference: [ RFC-to-be ]

Type: [ TDB-at-registration ]
Description: Min/Max Unidirectional Link Delay
Reference: [ RFC-to-be ]

Type: [ TDB-at-registration ]
Description: Unidirectional Delay Variation
Reference: [ RFC-to-be ]

Type: [ TDB-at-registration ]
Description: Unidirectional Link Loss
Reference: [ RFC-to-be ]

Type: [ TDB-at-registration ]
Description: Unidirectional Residual Bandwidth
Reference: [ RFC-to-be ]

Type: [ TDB-at-registration ]
Description: Unidirectional Available Bandwidth
Reference: [ RFC-to-be ]

Type: [ TDB-at-registration ]
Description: Unidirectional Utilized Bandwidth
Reference: [ RFC-to-be ]

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.
2014-12-15
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Menachem Dodge
2014-12-15
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Menachem Dodge
2014-12-11
08 Jean Mahoney Request for Last Call review by GENART is assigned to Martin Thomson
2014-12-11
08 Jean Mahoney Request for Last Call review by GENART is assigned to Martin Thomson
2014-12-11
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Ólafur Guðmundsson
2014-12-11
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Ólafur Guðmundsson
2014-12-10
08 Cindy Morgan IANA Review state changed to IANA - Review Needed
2014-12-10
08 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (OSPF Traffic Engineering (TE) Metric …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard


The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document:
- 'OSPF 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 2014-12-24. 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 RFC 3630 'Traffic Engineering
  (TE) Extensions to OSPF Version 2' such that network performance
  information can be distributed and collected in a scalable fashion.
  The information distributed using OSPF 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
http://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/

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

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

  http://datatracker.ietf.org/ipr/2442/
  http://datatracker.ietf.org/ipr/2199/



2014-12-10
08 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2014-12-10
08 Adrian Farrel Ballot writeup was changed
2014-12-10
08 Adrian Farrel Last call was requested
2014-12-10
08 Adrian Farrel Ballot approval text was generated
2014-12-10
08 Adrian Farrel IESG state changed to Last Call Requested from AD Evaluation
2014-12-10
08 Adrian Farrel Last call announcement was changed
2014-12-10
08 Adrian Farrel Last call announcement was generated
2014-12-10
08 Adrian Farrel
AD review
========

Authors,

Thanks for your work on this document. I am acting as "responsible" AD
as Alia (the usual AD for OSPF) is …
AD review
========

Authors,

Thanks for your work on this document. I am acting as "responsible" AD
as Alia (the usual AD for OSPF) is a co-author.

I've done my usual review on receiving the publication request. I see a
few small issues to attend to, but these do not need to hold up the IETF
last call. I will start that last call and submit my comments as last
call comments that you can handle along with any other comments you
receive.

Thanks,
Adrian

===

Please look for places where you have "proposed" something and change
that to "defined".

---

It would be good to include a reference for encoding floating point
integers. The usual is (I think)...

        IEEE, "IEEE Standard for Binary Floating-Point Arithmetic",
        Standard 754-1985, 1985 (ISBN 1-5593-7653-8).

---

Section 4.2.5

  Implementations MAY also permit the configuration of a static (non
  dynamic) offset value (in microseconds) to be added to the measured
  delay value, to facilitate the communication of operator specific
  delay constraints.

On the third reading I got it! I'm slow (I have a high delay :-)

The point here is that the measured value and the static value are added
together and the sum is transmitted in this field. I'd suggest...

  Implementations MAY also permit the configuration of a static (non
  dynamic) offset value (in microseconds) to be added to the measured
  delay value before encoding into this TLV, to facilitate the
  communication of operator specific delay constraints.

Similarly in 4.2.6.

---

4.2.7 appears out of sequence. But since it repeats the content of
4.2.4 I suggest you merge them and talk about the plurality of fields.

---

Section 7

"Sections 6 and 7 provide" should be 5 and 6.

---

Section 10

  "As per (RFC3630), unrecognized TLVs should be silently ignored"

There has been confusion about what 3630 means by "silently ignored".
In particular, some enthusiastic implementations thought this meant the
TLVs should be stripped from the LSA before it is propagated. I think it
is worth the few words to explicitly state that this is not the case.

---

Section 13

RFC 4203 is used in a normative way, please move it to the other
section.
2014-12-10
08 Adrian Farrel Ballot writeup was changed
2014-12-10
08 Adrian Farrel Ballot writeup was generated
2014-12-05
08 Adrian Farrel IESG state changed to AD Evaluation from Publication Requested
2014-12-05
08 Adrian Farrel
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    …
(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 OSPF 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.

      Finally, the draft was updated to include applicability to
      Advanced Multipath links.

      It should be noted that, consistent with the long-held IESG policy,
      there is a partner I-D for extensions to IS-IS
    (draft-ietf-isis-te-metric-extensions)

Document Quality:

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

Personnel:

      Acee Lindem is the Document Shepherd.
      Adrian Farrel 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 OSPF 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/?option=document_search&id=draft-ietf-ospf-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 OSPF Traffic Engineering sub-TLVs
      that are applicable to the OSPF TE Link TLV.

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

2014-12-05
08 Adrian Farrel
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    …
(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 OSPF 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.

      Finally, the draft was updated to include applicability to
      Advanced Multipath links.

Document Quality:

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

Personnel:

      Acee Lindem is the Document Shepherd.
      Adrian Farrel 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 OSPF 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/?option=document_search&id=draft-ietf-ospf-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 OSPF Traffic Engineering sub-TLVs
      that are applicable to the OSPF TE Link TLV.

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

2014-12-04
08 Alia Atlas Shepherding AD changed to Adrian Farrel
2014-12-04
08 Cindy Morgan Intended Status changed to Proposed Standard
2014-12-04
08 Cindy Morgan IESG process started in state Publication Requested
2014-12-04
08 (System) Earlier history may be found in the Comment Log for /doc/draft-ospf-te-metric-extensions/
2014-12-04
08 Cindy Morgan Working group state set to Submitted to IESG for Publication
2014-12-04
08 Cindy Morgan
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    …
(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 OSPF 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.

      Finally, the draft was updated to include applicability to
      Advanced Multipath links.

Document Quality:

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

Personnel:

      Acee Lindem 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 OSPF 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/?option=document_search&id=draft-ietf-ospf-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 OSPF Traffic Engineering sub-TLVs
      that are applicable to the OSPF TE Link TLV.

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

2014-12-04
08 Cindy Morgan Changed document writeup
2014-12-04
08 Cindy Morgan Notification list changed to "Acee Lindem" <acee@cisco.com>
2014-12-04
08 Cindy Morgan Document shepherd changed to Acee Lindem
2014-12-01
08 John Drake New version available: draft-ietf-ospf-te-metric-extensions-08.txt
2014-11-11
07 John Drake New version available: draft-ietf-ospf-te-metric-extensions-07.txt
2014-09-26
(System) Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-ospf-te-metric-extensions-06 and draft-ietf-isis-te-metric-extensions-03
2014-09-12
06 John Drake New version available: draft-ietf-ospf-te-metric-extensions-06.txt
2013-12-05
05 Spencer Giacalone New version available: draft-ietf-ospf-te-metric-extensions-05.txt
2013-09-17
(System) Posted related IPR disclosure: Cisco's Statement of IPR Related to draft-ietf-ospf-te-metric-extensions-04
2013-06-03
04 Spencer Giacalone New version available: draft-ietf-ospf-te-metric-extensions-04.txt
2013-02-25
03 Spencer Giacalone New version available: draft-ietf-ospf-te-metric-extensions-03.txt
2012-12-19
02 Spencer Giacalone New version available: draft-ietf-ospf-te-metric-extensions-02.txt
2012-05-18
01 Spencer Giacalone New version available: draft-ietf-ospf-te-metric-extensions-01.txt
2011-11-01
00 (System) New version available: draft-ietf-ospf-te-metric-extensions-00.txt