idnits 2.17.1 draft-ietf-ospf-ospfv3-traffic-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 233. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 210. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 223. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 239), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 4) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 80: '...IPv6 address. It MUST appear in exactl...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2004) is 7225 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2740 (ref. '1') (Obsoleted by RFC 5340) == Outdated reference: A later version (-08) exists of draft-ietf-tewg-diff-te-proto-07 == Outdated reference: A later version (-07) exists of draft-ietf-ospf-te-node-addr-00 Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Ishiguro 2 Internet Draft IP Infusion Inc. 3 Expiration Date: January 2005 T. Takada 4 IP Infusion Inc. 5 July 2004 7 Traffic Engineering Extensions to OSPF version 3 9 draft-ietf-ospf-ospfv3-traffic-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other intellectual property right (IPR) claims 15 of which he or she is aware have been or will be disclosed, and any 16 of which he or she becomes aware will be disclosed, in accordance 17 with Section 6 of RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 To view the list Internet-Draft Shadow Directories, see 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document describes extensions to OSPFv3 to support intra-area 42 Traffic Engineering (TE). 44 This document extends OSPFv2 TE to handle IPv6 networks. A new TLV 45 and several new sub-TLVs are defined to support IPv6 networks. 47 1. Applicability 49 OSPFv3 has a very flexible mechanism for adding new LS types. 50 Unknown LS types are flooded properly based on the flooding scope 51 bits in the LS type [1]. This document proposes the addition of the 52 Intra-Area-TE LSA to OSPFv3. 54 For Traffic Engineering, this document uses "Traffic Engineering 55 Extensions to OSPF" [2] as a base for TLV definitions. New sub-TLVs 56 are added to [2] to extend TE capabilities to IPv6 networks. Some 57 TLVs require clarification for OSPFv3 applicabilty. The new sub-TLVs 58 described in this document can also be carried in OSPFv2 as described 59 in [2]. 61 GMPLS [3] and the Diff-Serv aware MPLS Extensions [4] are based on 62 [2]. These functions can also be extended to OSPFv3 by utilizing the 63 TLV and sub-TLVs described in this document. 65 2. Node Address TLV 67 A stable IP address of the advertising router that is always 68 reachable is needed for traffic engineering. Node address TLV [5] 69 provides at least one routable node address. This satisfy 70 requirements of Traffic Engineering computation. In OSPFv3 TE, node 71 address TLV must be supported. 73 3. Router IPv6 Address TLV 75 The Router IPv6 Address TLV will advertise a reachable IPv6 address. 76 This is a stable IPv6 address that is always reachable if there is 77 connectivity to the OSPFv3 router. 79 The Router IPv6 Address TLV has type 3, length 16, and a value 80 containing a 16 octet local IPv6 address. It MUST appear in exactly 81 one Traffic Engineering LSA originated by an OSPFv3 router supporting 82 the TE extentions. 84 4. Link TLV 86 The Link TLV describes a single link and consists a set of sub-TLVs 87 [2]. All of sub-TLVs in [2] other than the Link ID sub-TLV are 88 applicable to OSPFv3. The Link ID sub-TLV can't be used in OSPFv3 89 due to the protocol differences between OSPFv2 and OSPFv3. 91 Three new sub-TLVs for the Link TLV are defined: 93 17 - Neighbor ID (8 octets) 94 18 - Local Interface IPv6 Address (16N octets) 95 19 - Remote Interface IPv6 Address (16N octets) 97 4.1 Link ID 99 The Link ID sub-TLV is used in OSPFv2 to identify the other end of 100 the link. In OSPFv3, the Neighbor ID sub-TLV should be used for link 101 identification. In OSPFv3, The Link ID sub-TLV should not be sent and 102 should be ignored upon receipt. 104 4.2 Neighbor ID 106 In OSPFv2, the Link ID is used to identify the other end of a link. 107 In OSPFv3, the combination of Neighbor Interface ID and Neighbor 108 Router ID are used for neighbor link identification. Both are adver- 109 tised in the Neighbor ID Sub-TLV. 111 The Neighbor ID sub-TLV has type 17, length 8, and contains the 4 112 octet Neighbor Interface ID and the 4 octet Neighbor Router ID. 113 Neighbor Interface ID and Neighbor Router ID values are the same as 114 described in RFC 2740 [1] A.4.3 Router-LSAs. 116 4.3 Local Interface IPv6 Address 118 The Local Interface IPv6 Address sub-TLV specifies the IPv6 119 address(es) of the interface corresponding to this link. If there 120 are multiple local addresses on the link, they are all listed in this 121 sub-TLV. Link-local address should not be included in this sub-TLV. 123 The Local Interface IPv6 Address sub-TLV has type 18, length 16N 124 (where N is the number of local addresses), and contains the link's 125 local addresses. 127 4.4 Remote Interface IPv6 Address 129 The Remote Interface IPv6 Address sub-TLV advertises the IPv6 130 address(es) associated with neighbor's interface. This Sub-TLV and 131 the Local Interface IPv6 address Sub-TLV are used to discern amongst 132 parallel links between OSPFv3 routers. If the Link Type is multi- 133 access, the Remote Interface IPv6 Address is set to ::. Link-local 134 addresses should not be contained in this sub-TLV. 136 The Remote Interface IPv6 Address sub-TLV has type 19, length 16N 137 (where N is the number of local addresses), and contains the link 138 neighbor's local addresses. 140 5. Intra-Area-TE-LSA 142 A new LS type is defined for the Intra-Area-TE LSA. The LSA function 143 code is 10, the U bit is set, and the scope is Area-scoping. When the 144 U bit is set to 1 an OSPFv3 router must flood the LSA at its defined 145 flooding scope even if it does not recognize the LS type [1]. 147 LSA function code LS Type Description 148 -------------------------------------------------------------------- 149 10 0xa00a Intra-Area-TE-LSA 151 The Link State ID of an Intra-Area-TE LSA will be the Interface ID of 152 the link. 154 6. Security Considerations 156 This memo does not create any new security issues for the OSPFv3 pro- 157 tocol [1] or OSPFv2 Traffic Engineering extenstions [2]. Security 158 considerations for OSPFv2 Traffic Engineering are covered in [2]. 160 7. Acknowledgements 162 Thanks to Vishwas Manral, Kireeti Kompella and Alex Zinin for their 163 comments. 165 8. Normative Reference 167 [1] R, Coltun, D. Ferguson, and J. Moy, "OSPF for IPv6", RFC 2740. 169 [2] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 170 Extensions to OSPF", RFC 3630. 172 9. Informative References 174 [3] K. Kompella, Y. Rekhter, "OSPF Extensions in Support of 175 Generalized MPLS", draft-ietf-ccamp-ospf-gmpls-extensions-12.txt, 176 work in progress. 178 [4] F. L. Faucheur, J. Boyle, K. Kompella, W. Townsend, D. Skalecki, 179 "Protocol extensions for support of Diff-Serv-aware MPLS Traffic 180 Engineering", draft-ietf-tewg-diff-te-proto-07.txt, work in 181 progress. 183 [5] R. Aggarwal, K. Kompella, "Advertising a Router's Local Addresses 184 in OSPF TE Extensions", draft-ietf-ospf-te-node-addr-00.txt, work 185 in progress. 187 10. Author's Address 189 Kunihiro Ishiguro 190 IP Infusion Inc. 191 111 W. St. John Street, Suite 910 192 San Jose CA 95113 193 e-mail: kunihiro@ipinfusion.com 195 Toshiaki Takada 196 IP Infusion Inc. 197 111 W. St. John Street, Suite 910 198 San Jose CA 95113 199 e-mail: takada@ipinfusion.com 201 Intellectual Property Statement 203 The IETF takes no position regarding the validity or scope of any 204 Intellectual Property Rights or other rights that might be claimed to 205 pertain to the implementation or use of the technology described in 206 this document or the extent to which any license under such rights 207 might or might not be available; nor does it represent that it has 208 made any independent effort to identify any such rights. Information 209 on the procedures with respect to rights in RFC documents can be found 210 in BCP 78 and BCP 79. 212 Copies of IPR disclosures made to the IETF Secretariat and any 213 assurances of licenses to be made available, or the result of an 214 attempt made to obtain a general license or permission for the use of 215 such proprietary rights by implementers or users of this specification 216 can be obtained from the IETF on-line IPR repository at 217 http://www.ietf.org/ipr. 219 The IETF invites any interested party to bring to its attention any 220 copyrights, patents or patent applications, or other proprietary 221 rights that may cover technology that may be required to implement 222 this standard. Please address the information to the IETF at 223 ietf-ipr@ietf.org. 225 Disclaimer of Validity 227 This document and the information contained herein are provided on an 228 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 229 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 230 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 231 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 232 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 233 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 235 Copyright Statement 237 Copyright (C) The Internet Society (2004). This document is subject 238 to the rights, licenses and restrictions contained in BCP 78, and 239 except as set forth therein, the authors retain all their rights. 241 Acknowledgment 243 Funding for the RFC Editor function is currently provided by the 244 Internet Society.