idnits 2.17.1 draft-ishiguro-ospf-ospfv3-traffic-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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? == No 'Intended status' indicated for this document; assuming Proposed Standard 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC2740], [OSPFV2-TE], [RFC2702]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (March 2003) is 7712 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) -- Missing reference section? 'RFC2702' on line 168 looks like a reference -- Missing reference section? 'RFC2740' on line 174 looks like a reference -- Missing reference section? 'OSPFV2-TE' on line 177 looks like a reference -- Missing reference section? 'OSPF-GMPLS' on line 181 looks like a reference -- Missing reference section? 'DIFFSERV-TE' on line 186 looks like a reference -- Missing reference section? 'OSPFV3' on line 116 looks like a reference -- Missing reference section? 'RFC2328' on line 172 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Ishiguro 3 Internet Draft IP Infusion Inc. 4 Expiration Date: September 2003 T. Takada 5 IP Infusion Inc. 6 March 2003 8 Traffic Engineering Extensions to OSPF version 3 10 draft-ishiguro-ospf-ospfv3-traffic-02.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document describes extensions to the OSPF version 3 to support 36 intra-area Traffic Engineering [RFC2702]. The OSPFv3 protocol is 37 specified in [RFC2740]. 39 This document expands [OSPFV2-TE] to make both IPv4 and IPv6 network 40 applicable. New sub-TLVs are defined to support IPv6 network. Use 41 of these new sub-TLVs are not limited in OSPF version 3. They can be 42 used in OSPF version 2. 44 1. Applicability 45 OSPFv3 has a very flexible mechanism in terms of adding new LS type. 46 Even the implementation does not know the LS types, the LSA is 47 properly flooded by LS type field. This document adds a new LSA type 48 Intra-Area-TE-LSA to OSPFv3. 50 For Traffic Engineering, this document refers [OSPFV2-TE] as a 51 basement TLV definition documentation. New sub-TLVs are added to 52 [OSPFV2-TE] to provide applicability to OSPFv3. Some TLVs need 53 clarification of their usage and value to apply to OSPFv3. Newly 54 added sub-TLVs can be used in [OSPFV2-TE] also. 56 Once [OSPFV2-TE] becomes applicable to OSPFv3, other mechanism such 57 as [OSPF-GMPLS] and [DIFFSERV-TE] which use [OSPFV2-TE] can be 58 applicable to OSPFv3. 60 2. Router Address TLV 62 In OSPFv3, Router Address TLV value should be a Router ID of the 63 advertising router. [OSPFV2-TE] states Router Address TLV is "a 64 stable IP address of the advertising router that is always reachable 65 if there is any connectivity to it". In OSPFv3, Router ID is not a 66 real IP address and is not reachable in IPv6 network. In OSPFv3 67 router identifier and IP address is completely separated. For 68 eachability information, Router IPv6 Address TLV is used. 70 The Router Address TLV is type 1, and has a length of 4, and the 71 value is the four octet OSPFv3 Router ID. It must appear in exactly 72 one Traffic Engineering LSA originated by a router. 74 3. Router IPv6 Address TLV 76 A new TLV is introduced to carry reachable IPv6 address. This IPv6 77 address is always reachable address to resolve the router's 78 reachability. 80 The Router IPv6 Address TLV is type 3, and has a length of 16. It 81 must appear in exactly one Traffic Engineering LSA originated by a 82 router. 84 4. Link TLV 86 The Link TLV describes a single link. It is constructed of a set of 87 sub-TLVs. Except Link ID sub-TLV, all of other sub-TLVs defined in 88 [OSPFV2-TE] can be applicable to OSPFv3. Link ID sub-TLV can't be 89 used in OSPFv3 due to the protocol difference between OSPFv2 and 90 OSPFv3. 92 Three new sub-TLVs are defined in this document: Neighbor ID, Local 93 Interface IPv6 address and Remote Interface IPv6 address. 95 17 - Neighbor ID (8 octets) 96 18 - Local Interface IPv6 Address (16N octets) 97 19 - Remote Interface IPv6 Address (16N octets) 99 4.1 Link ID 101 Link ID sub-TLV is used in OSPFv2 to identify the other end of the 102 link. In OSPFv3, Neighbor ID should be used instead of Link ID. In 103 OSPFv3, the Link ID sub-TLV should not be sent and ignored upon 104 receipt. 106 4.2 Neighbor ID 108 In OSPFv2, Link ID is a unique key to identify the other end of the 109 link. In OSPFv3, to identify the other end of the link, the combina- 110 tion of Neighbor Interface ID and Neighbor Router ID is needed. So 111 new sub-TLV Neighbor ID is defined. 113 The Neighbor ID sub-TLV is TLV type 17, and is 8 octets in length. 114 It contains 4 octet Neighbor Interface ID and 4 octet Neighbor Router 115 ID. Neighbor Interface ID and Neighbor Router ID value is the same 116 as described in [OSPFV3] A.4.3 Router-LSAs. 118 In OSPFv2, the Neighbor ID sub-TLV should not be sent and ignored 119 upon receipt. 121 4.3 Local Interface IPv6 Address 123 The Local Interface IPv6 Address sub-TLV specifies the IPv6 124 address(es) of the interface corresponding to this link. If there 125 are multiple local addresses on the link, they are all listed in this 126 sub-TLV. Link-local address should not be included in this sub-TLV. 128 The Local Interface IPv6 Address sub-TLV is TLV type 18, and is 16N 129 octets in length, where N is the number of local addresses. 131 4.4 Remote Interface IPv6 Address 133 The Remote Interface IPv6 Address sub-TLV specifies the IPv6 134 address(es) of the neighbor's interface corresponding to this link. 135 This and the local address are used to discern multiple parallel 136 links between systems. If the Link Type of the link is Multiaccess, 137 the Remote Interface IPv6 Address is set to ::. Link-local address 138 should not be included in this sub-TLV. 140 The Remote Interface IPv6 Address sub-TLV is TLV type 19, and is 16N 141 octets in length, where N is the number of neighbor addresses. 143 5. Intra-Area-TE-LSA 145 New LS type Intra-Area-TE-LSA is defined. LSA function code is 10. 146 U bit is 1 to indicate that router should handle the LSA even if the 147 router does not recognize the LSA's function code. Flooding scope is 148 Area Scoping. So Intra-Area-TE-LSA's LS Type is 0xa00a. 150 LSA function code LS Type Description 151 -------------------------------------------------------------------- 152 10 0xa00a Intra-Area-TE-LSA 154 Link State ID of Intra-Area-TE-LSA should be the Interface ID of the 155 link. 157 6. Security Considerations 159 Security issues are not discussed in this memo. 161 7. Acknowledgements 163 Thanks to Vishwas Manral, Kireeti Kompella and Alex Zinin for their 164 comments. 166 8. Reference 168 [RFC2702] RFC 2702, "Requirements for Traffic Engineering Over 169 MPLS," D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, 170 and J. McManus, September 1999. 172 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 174 [RFC2740] R. Coltun, D. Ferguson, J.Moy, "OSPF for IPv6", RFC2740, 175 December 1999. 177 [OSPFV2-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 178 Extensions to OSPF", 179 draft-katz-yeung-ospf-traffic-09.txt, work in progress. 181 [OSPF-GMPLS] K. Kompella, Y. Rekhter, "OSPF Extensions in Support of 182 Generalized MPLS", 183 draft-ietf-ccamp-ospf-gmpls-extensions-09.txt, work in 184 progress. 186 [DIFFSERV-TE] F. L. Faucheur, J. Boyle, K. Kompella, W. Townsend, 187 D. Skalecki, "Protocol extensions for support of 188 Diff-Serv-aware MPLS Traffic Engineering", 189 draft-ietf-tewg-diff-te-proto-02.txt, work in progress. 191 9. Author's Address 193 Kunihiro Ishiguro 194 IP Infusion Inc. 195 111 W. St. John Street, Suite 910 196 San Jose CA 95113 197 e-mail: kunihiro@ipinfusion.com 199 Toshiaki Takada 200 IP Infusion Inc. 201 111 W. St. John Street, Suite 910 202 San Jose CA 95113 203 e-mail: takada@ipinfusion.com