Skip to main content

A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link
RFC 5330

Revision differences

Document history

Date Rev. By Action
2017-05-16
12 (System) Changed document authors from "Kenji Kumaki, Alberto Bonda" to "Kenji Kumaki, Alberto Bonda, JP Vasseur, Matthew Meyer"
2015-10-14
12 (System) Notify list changed from mpls-chairs@ietf.org, draft-ietf-mpls-number-0-bw-te-lsps@ietf.org to (None)
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Pasi Eronen
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2008-10-22
12 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2008-10-22
12 Amy Vezza [Note]: 'RFC 5330' added by Amy Vezza
2008-10-17
12 (System) RFC published
2008-09-08
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2008-09-08
12 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2008-09-08
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2008-09-08
12 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2008-09-05
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2008-09-05
12 (System) IANA Action state changed to In Progress
2008-09-04
12 Amy Vezza IESG state changed to Approved-announcement sent
2008-09-04
12 Amy Vezza IESG has approved the document
2008-09-04
12 Amy Vezza Closed "Approve" ballot
2008-09-04
12 Ross Callon State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ross Callon
2008-09-04
12 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2008-09-04
12 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2008-09-01
12 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen
2008-09-01
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-09-01
12 (System) New version available: draft-ietf-mpls-number-0-bw-te-lsps-12.txt
2008-08-29
12 (System) Removed from agenda for telechat - 2008-08-28
2008-08-28
12 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2008-08-28
12 Russ Housley
[Ballot comment]
Ben Campbell provided comments on -09 of this document based on his
  Gen-ART Review, and they have not been addressed.  The Gen-ART …
[Ballot comment]
Ben Campbell provided comments on -09 of this document based on his
  Gen-ART Review, and they have not been addressed.  The Gen-ART Last
  Call comments were mostly editorial, and all minor.  Since the
  comments are minor, I am not entering a DISCUSS, but it is really
  bad form to ignore Last Call comments.  Please be more respectful
  of reviewer time in the future.
 
  Since others have entered DISCUSS positions on this document,
  please consider these comments from Ben Campbell.
 
 
  Abstract:

  Please expand TLV and IS-IS on first use. Expanding OSPF would not
  hurt, but it is probably well-known enough not to require expansion.

  s/"statistical assumption"/"statistical assumptions"
  (should be plural.)


  Requirements Language:

  It's a bit odd to see this prior to the Table of Contents. I usually 
  see it in the terminology section. I don't know if it matters.


  Section 1:

  Most of the terms are just acronym expansions. It might be nice to put 
  in short definitions, unless all of the terms are sufficiently well-
  known not to need definitions.


  Section 2, paragraph 1:

  I find the heavy use of parentheses to detract from the flow of the 
  paragraph. Also, when nesting parentheses, please use other symbols. 
  For example ( ... [ ... { ... } ... ] ... ) instead of ( ... ( ... 
  ( ... ) ... ) ... )


  paragraph 2:

  s/"other metric"/"other metrics"
  (should be plural.)


  "Unfortunately,
  for instance in the presence of ECMPs (Equal Cost Multi-Paths) in
  symmetrical networks when unconstrained TE LSPs are used, such
  metrics (e.g. path cost, number of hops, ...) are usually ineffective
  and may lead to poorly load balanced traffic."

  I found this sentence hard to follow. Can it be simplified?


  paragraph 3:

  s/"statistical assumption"/"statistical assumptions"
  (should be plural.)

  Also, can you offer a sentence or two explaining what you mean by 
  "statistical assumptions"? I think I know what you mean, but I don't 
  think it will be obvious to all readers.


  paragraph 5:

  A comma would be a better choice than parentheses in this context.


  paragraph 7:

  Why is it okay to omit unconstrained TE LSPs that are provisioned?


  Section 3.1, definition of "Value"

  Is the encoding of the numeric value well-known for this context, or 
  should this document specify it?


  Section 3.2, definition of "Value"

  Is the encoding of the numeric value well-known for this context, or 
  should this document specify it?


  Section 4 , title:

  I'm not sure what the title means. I suggest "Procedures".


  paragraph 1:

  Is that intended to be a normative SHOULD?


  Section 5:

  The text said the type numbers were to be assigned by IANA, with 23 
  being a suggested value. That is not clear in the IANA considerations.


  Section 6:

  Can the information carried in this new parameter ever be sensitive, 
  or useful to an attacker? I'm not saying it is, but it might be useful 
  to mention this one way or another in the security considerations.
2008-08-28
12 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2008-08-28
12 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2008-08-28
12 Tim Polk
[Ballot discuss]
Another issue that can be resolved with an RFC Editor Note:

In addition to the changes requested by Pasi, I believe an informative …
[Ballot discuss]
Another issue that can be resolved with an RFC Editor Note:

In addition to the changes requested by Pasi, I believe an informative reference
to draft-ietf-mpls-mpls-and-gmpls-security-framework would be appropriate
in the security considerations section.  While I expect that document to endure
several more revision cycles, I think we should start referencing it now!

[Note that this would resolve the much more general observations from Phil
Hallam-Baker's secdir review.]
2008-08-28
12 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2008-08-28
12 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2008-08-28
12 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2008-08-27
12 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2008-08-27
12 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2008-08-27
12 David Ward [Ballot Position Update] New position, Yes, has been recorded by David Ward
2008-08-27
12 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2008-08-26
12 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2008-08-26
12 Pasi Eronen
[Ballot discuss]
All these could be easily fixed by an RFC Editor note, hopefully
allowing this DISCUSS to go away before the telechat:

The document …
[Ballot discuss]
All these could be easily fixed by an RFC Editor note, hopefully
allowing this DISCUSS to go away before the telechat:

The document should reference [draft-ietf-isis-te-bis] instead
of [RFC3784] (the latter would be a downref).

Section 6: The reference to RFC 2470 ("Transmission of IPv6 Packets
over Token Ring Networks") probably intends to point to RFC 5340
(which obsoletes RFC 2740).

Section 6: The text should say security considerations for IS-IS
are discussed in [draft-ietf-isis-rfc3567bis] (this is what we
said in the other IS-IS extensions, too; RFC 1195 doesn't
really have meaningful security considerations text).
2008-08-26
12 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to Discuss from No Objection by Pasi Eronen
2008-08-26
12 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2008-08-25
12 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2008-08-21
12 Samuel Weiler Request for Telechat review by SECDIR is assigned to Phillip Hallam-Baker
2008-08-21
12 Samuel Weiler Request for Telechat review by SECDIR is assigned to Phillip Hallam-Baker
2008-08-20
12 Ross Callon [Ballot Position Update] New position, Yes, has been recorded for Ross Callon
2008-08-20
12 Ross Callon Ballot has been issued by Ross Callon
2008-08-20
12 Ross Callon Created "Approve" ballot
2008-08-20
12 Ross Callon Placed on agenda for telechat - 2008-08-28 by Ross Callon
2008-08-20
12 Ross Callon State Changes to IESG Evaluation from AD Evaluation::AD Followup by Ross Callon
2008-08-19
11 (System) New version available: draft-ietf-mpls-number-0-bw-te-lsps-11.txt
2008-08-19
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-08-19
10 (System) New version available: draft-ietf-mpls-number-0-bw-te-lsps-10.txt
2008-07-11
12 Ross Callon State Changes to AD Evaluation::Revised ID Needed from Waiting for AD Go-Ahead::External Party by Ross Callon
2008-05-02
12 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Phillip Hallam-Baker.
2008-05-01
12 Ross Callon State Changes to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead by Ross Callon
2008-04-25
12 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-04-21
12 Amanda Baber
IANA Last Call comments:

Action 1:

Upon approval of this document, the IANA will make the following
assignments in the "IS-IS TLV Codepoints per [ …
IANA Last Call comments:

Action 1:

Upon approval of this document, the IANA will make the following
assignments in the "IS-IS TLV Codepoints per [RFC3563]" registry at
http://www.iana.org/assignments/isis-tlv-codepoints
sub-registry "Sub-TLVs for TLV 22"

Type Description Reference
------- -------------------------------------------- ---------
tbd(23) Unconstrained TE LSP Count
[RFC-mpls-number-0-bw-te-lsps-09]


Action 2:

Upon approval of this document, the IANA will make the following
assignments in the "Open Shortest Path First (OSPF) Traffic
Engineering TLVs" registry at
http://www.iana.org/assignments/ospf-traffic-eng-tlvs
sub-registry "Types for sub-TLVs of TE Link TLV (Value 2)"

Value Sub-TLV Reference
----------- ------------------------------------------------------ ---------
tbd(23) Unconstrained TE LSP Count
[RFC-mpls-number-0-bw-te-lsps-09]


We understand the above to be the only IANA Actions for this
document.
2008-04-12
12 Samuel Weiler Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker
2008-04-12
12 Samuel Weiler Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker
2008-04-11
12 Amy Vezza Last call sent
2008-04-11
12 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-04-11
12 Ross Callon Last Call was requested by Ross Callon
2008-04-11
12 (System) Ballot writeup text was added
2008-04-11
12 (System) Last call text was added
2008-04-11
12 (System) Ballot approval text was added
2008-04-11
12 Ross Callon State Changes to Last Call Requested from Publication Requested by Ross Callon
2008-04-02
12 Cindy Morgan
A Link-Type sub-TLV to convey the number of Traffic Engineering Label
Switched Paths signalled with zero reserved bandwidth across a link
(draft-ietf-mpls-number-0-bw-te-lsps-09)


Requested …
A Link-Type sub-TLV to convey the number of Traffic Engineering Label
Switched Paths signalled with zero reserved bandwidth across a link
(draft-ietf-mpls-number-0-bw-te-lsps-09)


Requested Publication Status: Proposed Standard

------------------------------------------------------------------------

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication?

Yes.

Both mpls wg co-chairs reviewed this version of the ID. Based on the WG
comments, we believe the ID is ready for publication. See nits section!


1.b) Has the document had adequate review from both key WG members
and key non-WG members?

Yes, the document has been through wg last call with good and constructive
comments, it has also been reviewed by subject-matter experts that are
WG members.

Do you have any concerns about the
depth or breadth of the reviews that have been performed?

Well - I just had and asked the OSPF and IS-IS chairs if they thinks it
is a good idea to wg last call it in their wg's.

We've also had this discussion and Ross said:

"Okay. In my opinion the amount of review seems generous considering the
small size of the draft, the extent to which the draft is consistent
with other similar information which is already defined and used in
current deployments, and the simplicity of the draft.

Given that this is standards track, we need to do an IETF last call on
the draft anyway.

Thus, how about if someone (one of the WG chairs) sends me a PROTO
writeup for the document. Then I will start the last call, and we can
flag the IETF last call in email to the appropriate WG mailing lists
(OSPF, IS-IS, CCAMP, and MPLS). The specific reviews that Dave has
requested can occur in parallel."

This is OK with the wg chairs.


1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

None other than what is mentioned above.

1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

No. The internet-draft was produced by working group memebers with
expereince from LDP implentations and testing.


1.e) 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?

This document represents the WG consensus as a whole: the WG as a whole
understands and agrees with it.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director.

No.

1.g) Have the chairs verified that the document adheres to all of the
ID nits? (see http://www.ietf.org/ID-Checklist.html).

The ID-nits tool gives the following output:

== Outdated reference: A later version (-10) exists of
draft-ietf-ospf-ospfv3-traffic-09

-- Possible downref: Normative reference to a draft: ref.
'I-D.ietf-ospf-ospfv3-traffic' (No intended status found in state file
of draft-ietf-ospf-ospfv3-traffic)

** Downref: Normative reference to an Informational RFC: RFC 3784


Summary: 1 error (**), 1 warning (==), 1 comment (--).

The outdated reference is easily fixed, and the down ref is *wrong*
since the ospfv3-traffic draft clearly says it is intended for
standards track.

1.h) Is the document split into normative and informative references?

Yes.

Are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear state?
(note here that the RFC editor will not publish an RFC with
normative references to IDs, it will delay publication until all
such IDs are also ready for publication as RFCs.)

No. As we understands it the ospfv3-traffic is of about the same
maturity as the zero-bw draft and should be progressed shortly.

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:

* Technical Summary

* Working Group Summary

* Protocol Quality

1.j) Please provide such a write-up. Recent examples can be found in
the "protocol action" announcements for approved documents.

--- Technical Summary

A common strategy in MPLS fast recovery is to rely on local repair,
this strategy migght rely on MPLS fast reroute. What is done is to
set up a full mmesh of TE LSPs, signalled with zero bandwidth between
LSRs to protoct TE LSPs. There may be several kinds of failures, e.g.
links, SRLGs or node failures. When traffic is routed on to TE LSP
without (unconstrained LSPs) signaled bandwidth it simply follows that
IGP shotest Path.

When a When protection actions are triggered for constrained and
unconstrained the result may vary drastically. For a constrained
LSP the the reoptimization process is based on the same metrics that
were used to set up the LSP in the first place. Unfortunately,
for instance in the presence of ECMPs in symmetrical networks such
metrics very iften are ineffective and may lead to poorly load balanced
traffic.

Instead it is possible to make statistical assumptions traffic aggregates
that is carried on unconstrained TE LSPs. Algorithms can be designed to
load balance unconstrained TE LSPs over a set of equal cost paths. To
have such paradims work it is neessary to know the number of unconstrained
TE LSPs on each link. This draft defines a method to distribute that
knowledge.

============>>>>

--- Working Group Summary

The Working Group has consensus to publish this document as a
Proposed Standard.

--- Protocol Quality

The document has been reviewed by experts form the MPLS working
group as well as being lst called in the working, the comments received
from the experts and the working has been addressed and the document
updated.

--- Implementations

We don't know of any implementations of the specification.
2008-04-02
12 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2008-02-06
09 (System) New version available: draft-ietf-mpls-number-0-bw-te-lsps-09.txt
2007-12-06
08 (System) New version available: draft-ietf-mpls-number-0-bw-te-lsps-08.txt
2007-11-16
07 (System) New version available: draft-ietf-mpls-number-0-bw-te-lsps-07.txt
2007-06-29
06 (System) New version available: draft-ietf-mpls-number-0-bw-te-lsps-06.txt
2006-12-12
05 (System) New version available: draft-ietf-mpls-number-0-bw-te-lsps-05.txt
2006-12-08
04 (System) New version available: draft-ietf-mpls-number-0-bw-te-lsps-04.txt
2006-12-01
03 (System) New version available: draft-ietf-mpls-number-0-bw-te-lsps-03.txt
2006-06-27
02 (System) New version available: draft-ietf-mpls-number-0-bw-te-lsps-02.txt
2006-05-24
01 (System) New version available: draft-ietf-mpls-number-0-bw-te-lsps-01.txt
2006-05-16
00 (System) New version available: draft-ietf-mpls-number-0-bw-te-lsps-00.txt