Subject: I-D ACTION:draft-katz-yeung-ospf-traffic-10.txt

From: [email-masked]
Date: Thu, 19 Jun 2003 07:31:25 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF.

        Title           : Traffic Engineering Extensions to OSPF Version 2
        Author(s)       : D. Katz, D. Yeung, K. Kompella
        Filename        : draft-katz-yeung-ospf-traffic-10.txt
        Pages           : 15
        Date            : 2003-6-18

This document describes extensions to the OSPF protocol version 2 to
support intra-area Traffic Engineering, using Opaque Link State
Advertisements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-10.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-katz-yeung-ospf-traffic-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-katz-yeung-ospf-traffic-10.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Rohit Dube <[email-masked]>
Date: Thu, 19 Jun 2003 09:40:54 -0400

Folks,

Attached below is the output of
`diff -u draft-katz-yeung-ospf-traffic-09.txt draft-katz-yeung-ospf-traffic-10.txt`
(Apologies in advance for the rather larger attachment created by the
output of diff.)

Please review. Specifically, note the changes in the IANA considerations
section.

Thanks,
--rohit.

--- draft-katz-yeung-ospf-traffic-09.txt        Fri Nov 22 11:13:40 2002
+++ draft-katz-yeung-ospf-traffic-10.txt        Thu Jun 19 09:31:47 2003
@@ -3,14 +3,13 @@

-
 Network Working Group                                            D. Katz
-Internet Draft                                          Juniper Networks
-Category: Standards Track                                       D. Yeung
-Expires: April 2003                                     Procket Networks
-draft-katz-yeung-ospf-traffic-09.txt                         K. Kompella
-                                                        Juniper Networks
-                                                            October 2002
+Internet Draft                                               K. Kompella
+Updates: 2370                                           Juniper Networks
+See Also: 2328                                                  D. Yeung
+Category: Standards Track                               Procket Networks
+Expires: December 2003                                         June 2003
+draft-katz-yeung-ospf-traffic-10.txt

             Traffic Engineering Extensions to OSPF Version 2
@@ -41,7 +40,7 @@

 Copyright Notice

-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.

@@ -57,7 +56,7 @@

 Katz, Yeung, Kompella        Standards Track                    [Page 1]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003

 Abstract
@@ -71,24 +70,24 @@

    (This section to be removed before publication).

-   Per comments from the OSPF WG mailing list, the following changes
-   were made:
-
-    - State that operation over multi-access networks with more than two
-      TE devices is not expressly forbidden.
-    - Fix figure in 2.3.1.
-    - Specify that a Remote Interface IP Address sub-TLV is optional for
-      a multi-access link.
-
-
-
-
-
+   Per comments from the IETF-wide Last Call, section 1 re-emphasizes
+   that this document does not address flooding inter-area.

+   Re-iterated that TE LSAs are to be flooded as per RFC 2370 Type 10
+   LSAs.

+   Also, fixed references: some docs cited as "work in progress" are now
+   RFCs; references for unnumbered interfaces moved to Informative.

+   The IANA Considerations section has been re-written.  There are now
+   three types of ranges: Standards Action, Experimental and unassigned.
+   Values from the last range MUST NOT be assigned until a Standards
+   Track RFC defines the IANA Considerations for that range.

+   Removed reference to OSPF Extensions for GMPLS; adjusted reference
+   numbering.

+   Fixed front page headers.

@@ -113,7 +112,7 @@

 Katz, Yeung, Kompella        Standards Track                    [Page 2]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003

 1. Introduction
@@ -130,7 +129,13 @@
    distributing this information within a given OSPF area.  This
    topology does not necessarily match the regular routed topology,
    though this proposal depends on Network LSAs to describe multiaccess
-   links.
+   links.  This document purposely does not say how the mechanisms
+   described here can be used for traffic engineering across multiple
+   OSPF areas; that task is left to future documents.  Furthermore, no
+   changes have been made to the operation of OSPFv2 flooding; in
+   particular, if non-TE capable nodes exist in the topology, they MUST
+   flood TE LSAs as any other type 10 (area-local scope) Opaque LSAs
+   (see [7]).

 1.1. Applicability

@@ -158,20 +163,20 @@

    In "local constraint-based source routing", a router R can compute a
    path from a source node A to a destination node B; typically, A is R
-   itself, and B is specified by a "router address" (see below).  This
-   path may be subject to various constraints on the attributes of the
-   links and nodes that the path traverses, e.g., use green links that
-   have unreserved bandwidth of at least 10Mbps.  This path could then
-   be used to carry some subset of the traffic from A to B, forming a
-   simple but effective means of traffic engineering.  How the subset of

 Katz, Yeung, Kompella        Standards Track                    [Page 3]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003

+   itself, and B is specified by a "router address" (see below).  This
+   path may be subject to various constraints on the attributes of the
+   links and nodes that the path traverses, e.g., use green links that
+   have unreserved bandwidth of at least 10Mbps.  This path could then
+   be used to carry some subset of the traffic from A to B, forming a
+   simple but effective means of traffic engineering.  How the subset of
    traffic is determined, and how the path is instantiated is beyond the
    scope of this document; suffice it to say that one means of defining
    the subset of traffic is "those packets whose IP destinations were
@@ -204,20 +209,14 @@
    reservation state of multi-access networks is for further study.

    This document also does not support unnumbered links.  This
-   deficiency is addressed in [4]; see also [5] and [6].
+   deficiency will be addressed in future documents; see also [4] and
+   [5].

 1.3. Conventions

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [7].
-
-
-
-
-
-
-
+   document are to be interpreted as described in RFC 2119 [6].

@@ -225,14 +224,14 @@

 Katz, Yeung, Kompella        Standards Track                    [Page 4]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003

 2. LSA Format

 2.1. LSA type

-   This extension makes use of the Opaque LSA [8].
+   This extension makes use of the Opaque LSA [7].

    Three types of Opaque LSAs exist, each of which has different
    flooding scope.  This proposal uses only Type 10 LSAs, which have
@@ -281,7 +280,7 @@

 Katz, Yeung, Kompella        Standards Track                    [Page 5]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003

       0                   1                   2                   3
@@ -309,6 +308,9 @@
      |              Type             |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Value...                           |
+     .                                                               .
+     .                                                               .
+     .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The Length field defines the length of the value portion in octets
@@ -325,10 +327,7 @@

    An LSA contains one top-level TLV.

-   There are two top-level TLVs defined:

-     1 - Router Address
-     2 - Link

@@ -337,8 +336,13 @@

 Katz, Yeung, Kompella        Standards Track                    [Page 6]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003
+

+   There are two top-level TLVs defined:
+
+     1 - Router Address
+     2 - Link

 2.4.1. Router Address TLV

@@ -377,11 +381,6 @@

    The Link TLV is type 2, and the length is variable.

-   The following sub-TLVs are defined:
-
-
-
-

@@ -393,8 +392,10 @@

 Katz, Yeung, Kompella        Standards Track                    [Page 7]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003
+

+   The following sub-TLVs of the Link TLV are defined:

      1 - Link type (1 octet)
      2 - Link ID (4 octets)
@@ -428,7 +429,7 @@
    point in front of it.  Thus the above represents the value
         (-1)**(S) * 2**(Exponent-127) * (1 + Fraction)

-   For more details, refer to [9].
+   For more details, refer to [8].

 2.5. Sub-TLV Details

@@ -445,11 +446,9 @@

-
-
 Katz, Yeung, Kompella        Standards Track                    [Page 8]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003

 2.5.2. Link ID
@@ -505,7 +504,7 @@

 Katz, Yeung, Kompella        Standards Track                    [Page 9]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003

    The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in
@@ -561,7 +560,7 @@

 Katz, Yeung, Kompella        Standards Track                   [Page 10]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003

 3. Elements of Procedure
@@ -594,51 +593,56 @@
    calculated and ought to work.

-5. Normative References
+Normative References
+
+   [1]  Moy, J., "OSPF Version 2", RFC 2328, April 1998.
+
+   [6]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [7]  Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998.
+
+   [8]  IEEE, "IEEE Standard for Binary Floating-Point Arithmetic",
+        Standard 754-1985, 1985 (ISBN 1-5593-7653-8).

-   [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998.

-   [4] Kompella, K., Rekhter, Y., et al, "OSPF Extensions in Support of
-       Generalized MPLS," work in progress.

-   [6] Kompella, K., and Y. Rekhter, "Signalling Unnumbered Links in
-       RSVP-TE," work in progress.

-   [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
-       Levels", BCP 14, RFC 2119, March 1997.

-   [8] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998.

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

 Katz, Yeung, Kompella        Standards Track                   [Page 11]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003

-6. Informative References
+Informative References

-   [2] Awduche, D., et al, "Requirements for Traffic Engineering Over
-   MPLS," RFC 2702, September 1999.
+   [2]  Awduche, D., et al, "Requirements for Traffic Engineering Over
+        MPLS," RFC 2702, September 1999.

-   [3] Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering,"
-   work in progress.
+   [3]  Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering,"
+        work in progress.

-   [5] Kompella, K., Rekhter, Y., and A. Kullberg, "Signalling
-   Unnumbered Links in CR-LDP," work in progress.
+   [4]  Kompella, K., and Y. Rekhter, "Signalling Unnumbered Links in
+        Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE),"
+        RFC 3477, January 2003.

-   [10] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA
-   Considerations Section in RFCs", RFC 2434, BCP 26, October 1998.
+   [5]  Kompella, K., Rekhter, Y., and A. Kullberg, "Signalling
+        Unnumbered Links in CR-LDP (Constraint-Routing Label
+        Distribution Protocol)," RFC 3480, February 2003.

-   [11] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital
-   Signatures", RFC 2154, June 1997.
+   [9]  Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital
+        Signatures", RFC 2154, June 1997.
+
+   [10] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", RFC 2434, BCP 26, October 1998.

-7. Security Considerations
+Security Considerations

    This document specifies the contents of Opaque LSAs in OSPFv2.  As
    Opaque LSAs are not used for SPF computation or normal routing, the
@@ -648,39 +652,60 @@
    securing the transmission of normal OSPF LSAs be applied equally to
    all Opaque LSAs, including the TE LSAs specified here.

-   Note that the mechanisms in [1] and [11] apply to Opaque LSAs.  It is
+   Note that the mechanisms in [1] and [9] apply to Opaque LSAs.  It is
    suggested that any future mechanisms proposed to secure/authenticate
    OSPFv2 LSA exchanges be made general enough to be used with Opaque
    LSAs.

-8. IANA Considerations

-   The top level Types in a TE LSA as well as Types for sub-TLVs in a TE
-   Link TLV are to be registered with IANA.

-   Following the guidelines set in [10], top level Types in TE LSAs from
-   3 through 32767 are to be assigned by Expert Review (the said Expert
-   to be decided by the IESG).  Types from 32768 through 65535 are
-   reserved for Private Use.  In all cases, assigned values Types MUST
-   be registered with IANA.
-
-   Also, sub-Types of a TE Link TLV from 10 to 32767 are to be assigned
-   by Expert Review; values from 32768 through 32772 are reserved for
-   Private Use; and values from 32773 through 65535 are to be assigned
+
+
+
+
+
+
+

 Katz, Yeung, Kompella        Standards Track                   [Page 12]

-Internet Draft           TE Extensions to OSPFv2            October 2002
+Internet Draft           TE Extensions to OSPFv2               June 2003
+

+IANA Considerations

-   First Come First Served.  In all cases, assigned values are to be
-   registered with IANA.
+   The top level Types in a TE LSA as well as Types for sub-TLVs for
+   each top level Type are to be registered with IANA, except as noted.

+   Here are the guidelines (using terms defined in [10]) for the
+   assignment of top level Types in TE LSAs:
+    o Types in the range 3-32767 are to be assigned via Standards
+      Action.
+    o Types in the range 32768-32777 are for experimental use; these
+      will not be registered with IANA, and MUST NOT be mentioned by
+      RFCs.
+    o Types in the range 32778-65535 are not to be assigned at this
+      time.  Before any assignments can be made in this range, there
+      MUST be a Standards Track RFC that specifies IANA Considerations
+      that covers the range being assigned.
+
+   The guidelines for the assignment of types for sub-TLVs in a TE LSA
+   are as follows:
+    o Types in the range 10-32767 are to be assigned via Standards
+      Action.
+    o Types in the range 32768-32777 are for experimental use; these
+      will not be registered with IANA, and MUST NOT be mentioned by
+      RFCs.
+    o Types in the range 32778-65535 are not to be assigned at this
+      time.  Before any assignments can be made in this range, there
+      MUST be a Standards Track RFC that specifies IANA Considerations
+      that covers the range being assigned.

-9. Authors' Addresses
+
+Authors' Addresses

    Dave Katz
    Juniper Networks
@@ -698,6 +723,14 @@
    Phone:  +1 408 635-7900
    Email: [email-masked]

+
+
+
+Katz, Yeung, Kompella        Standards Track                   [Page 13]
+
+Internet Draft           TE Extensions to OSPFv2               June 2003
+
+
    Kireeti Kompella
    Juniper Networks
    1194 N. Mathilda Ave.
@@ -707,7 +740,7 @@
    Email:  [email-masked]

-10. IPR Notices
+IPR Notice

    The IETF takes no position regarding the validity or scope of any
    intellectual property or other rights that might be claimed to
@@ -724,23 +757,15 @@
    be obtained from the IETF Secretariat.

    The IETF invites any interested party to bring to its attention any
-
-
-
-Katz, Yeung, Kompella        Standards Track                   [Page 13]
-
-Internet Draft           TE Extensions to OSPFv2            October 2002
-
-
    copyrights, patents or patent applications, or other proprietary
    rights which may cover technology that may be required to practice
    this standard.  Please address the information to the IETF Executive
    Director.

-11. Full Copyright Notice
+Full Copyright Notice

-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
@@ -754,6 +779,14 @@
    developing Internet standards in which case the procedures for
    copyrights defined in the Internet Standards process must be
    followed, or as required to translate it into languages other than
+
+
+
+Katz, Yeung, Kompella        Standards Track                   [Page 14]
+
+Internet Draft           TE Extensions to OSPFv2               June 2003
+
+
    English.

    The limited permissions granted above are perpetual and will not be
@@ -767,7 +800,10 @@
    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

+Acknowledgement

+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.

@@ -783,5 +819,24 @@

-Katz, Yeung, Kompella        Standards Track                   [Page 14]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Katz, Yeung, Kompella        Standards Track                   [Page 15]

---

From: Rohit Dube <[email-masked]>
Date: Mon, 23 Jun 2003 09:11:05 -0400

Folks,

This draft will be IETF Last-Called shortly (with CC to
OSPF WG) and then submitted for IESG review.

The IANA section has changed significantly from the previous
version as the IESG objected to the Private Use and (my impression)
to a lesser degree with the FCFS range. This has now been fixed
(see diff excerpt below).

If you have comments, now would be the time to make them.

Best,
--rohit.

On Thu, 19 Jun 2003 09:40:54 -0400 Rohit Dube writes:
=>Folks,
=>
=>Attached below is the output of
=>`diff -u draft-katz-yeung-ospf-traffic-09.txt draft-katz-yeung-ospf-traffic-1
>0.txt`
=>(Apologies in advance for the rather larger attachment created by the
=>output of diff.)
=>
=>Please review. Specifically, note the changes in the IANA considerations
=>section.
=>
=>Thanks,
=>--rohit.
=>
=>
=>--- draft-katz-yeung-ospf-traffic-09.txt        Fri Nov 22 11:13:40 2002
=>+++ draft-katz-yeung-ospf-traffic-10.txt        Thu Jun 19 09:31:47 2003
[snip]
=>-8. IANA Considerations
=>
=>-   The top level Types in a TE LSA as well as Types for sub-TLVs in a TE
=>-   Link TLV are to be registered with IANA.
=>
=>-   Following the guidelines set in [10], top level Types in TE LSAs from
=>-   3 through 32767 are to be assigned by Expert Review (the said Expert
=>-   to be decided by the IESG).  Types from 32768 through 65535 are
=>-   reserved for Private Use.  In all cases, assigned values Types MUST
=>-   be registered with IANA.
=>-
=>-   Also, sub-Types of a TE Link TLV from 10 to 32767 are to be assigned
=>-   by Expert Review; values from 32768 through 32772 are reserved for
=>-   Private Use; and values from 32773 through 65535 are to be assigned
=>+
=>+
=>+
=>+
=>+
=>+
=>+
=>
=>
=>
=> Katz, Yeung, Kompella        Standards Track                   [Page 12]
=>
=>-Internet Draft           TE Extensions to OSPFv2            October 2002
=>+Internet Draft           TE Extensions to OSPFv2               June 2003
=>+
=>
=>+IANA Considerations
=>
=>-   First Come First Served.  In all cases, assigned values are to be
=>-   registered with IANA.
=>+   The top level Types in a TE LSA as well as Types for sub-TLVs for
=>+   each top level Type are to be registered with IANA, except as noted.
=>
=>+   Here are the guidelines (using terms defined in [10]) for the
=>+   assignment of top level Types in TE LSAs:
=>+    o Types in the range 3-32767 are to be assigned via Standards
=>+      Action.
=>+    o Types in the range 32768-32777 are for experimental use; these
=>+      will not be registered with IANA, and MUST NOT be mentioned by
=>+      RFCs.
=>+    o Types in the range 32778-65535 are not to be assigned at this
=>+      time.  Before any assignments can be made in this range, there
=>+      MUST be a Standards Track RFC that specifies IANA Considerations
=>+      that covers the range being assigned.
=>+
=>+   The guidelines for the assignment of types for sub-TLVs in a TE LSA
=>+   are as follows:
=>+    o Types in the range 10-32767 are to be assigned via Standards
=>+      Action.
=>+    o Types in the range 32768-32777 are for experimental use; these
=>+      will not be registered with IANA, and MUST NOT be mentioned by
=>+      RFCs.
=>+    o Types in the range 32778-65535 are not to be assigned at this
=>+      time.  Before any assignments can be made in this range, there
=>+      MUST be a Standards Track RFC that specifies IANA Considerations
=>+      that covers the range being assigned.
[snip]