Re: I-D ACTION:draft-katz-yeung-ospf-traffic-10.txt
Rohit Dube <rohit@XEBEO.COM> Thu, 19 June 2003 13:40 UTC
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17508 for <ospf-archive@LISTS.IETF.ORG>; Thu, 19 Jun 2003 09:40:57 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00A20A17@cherry.ease.lsoft.com>; Thu, 19 Jun 2003 9:40:56 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45943107 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 Jun 2003 09:40:55 -0400
Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 19 Jun 2003 09:40:55 -0400
Received: (qmail 10618 invoked from network); 19 Jun 2003 13:40:54 -0000
Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 19 Jun 2003 13:40:54 -0000
Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id JAA23590 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 19 Jun 2003 09:40:54 -0400
Message-ID: <200306191340.JAA23590@bigbird.xebeo.com>
Date: Thu, 19 Jun 2003 09:40:54 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Rohit Dube <rohit@XEBEO.COM>
Subject: Re: I-D ACTION:draft-katz-yeung-ospf-traffic-10.txt
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: Your message of "Thu, 19 Jun 2003 07:31:25 EDT." <200306191131.HAA09353@ietf.org>
Precedence: list
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: myeung@procket.com
+
+
+
+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: kireeti@juniper.net
-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]
- I-D ACTION:draft-katz-yeung-ospf-traffic-10.txt Internet-Drafts
- Re: I-D ACTION:draft-katz-yeung-ospf-traffic-10.t… Rohit Dube