idnits 2.17.1 draft-ishiguro-ospf-ospfv3-traffic-00.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.) ** 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 (October 2002) is 7863 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 122 looks like a reference -- Missing reference section? 'RFC2740' on line 128 looks like a reference -- Missing reference section? 'OSPFV2-TE' on line 131 looks like a reference -- Missing reference section? 'OSPFV3' on line 84 looks like a reference -- Missing reference section? 'RFC2328' on line 126 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 7 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: May 2003 T. Takada 5 IP Infusion Inc. 6 October 2002 8 Traffic Engineering Extensions to OSPF version 3 10 draft-ishiguro-ospf-ospfv3-traffic-00.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 Traffic Engineering [RFC2702]. The OSPFv3 protocol is specified in 37 [RFC2740]. 39 This document extends OSPFv3 protocol by specifying new LS type for 40 exchanging traffic engineering information. This document defines 41 new TLV to [OSPFV2-TE] to make it work with IPv6 network. Besides 42 the new TLV, other TLV is completely same as [OSPFV2-TE]. 44 1. Applicability 45 OSPFv3 has a very flexible mechanism for adding new LS type. Even 46 the implementation does not know the LS types, the LSA is properly 47 flooded by LS type field. This document add a new LSA type Traffic 48 Engineering LSA to OSPFv3. 50 For Traffic Engineering, this document use [OSPFV2-TE] as predefined 51 TLV document. Main purpose of this document is making [OSPFV2-TE] 52 applicable to IPv6 network with minimum change. 54 2. Router Address TLV 56 [OSPFV2-TE] defines Router Address TLV. [OSPFV2-TE] said it is 57 stable IP address of the advertising router and the address is always 58 reachable. For IPv6 network it is not real IP address neither it is 59 not reachable. The Router Address TLV is used to identify Router- 60 LSA. So in OSPFv3 it must be Router ID of the advertising router. 61 It is much like Router ID TLV rather than Router Address TLV. Router 62 Address TLV can be used as it is using Router ID value for it. 64 3. Link TLV 66 Almost Link TLV can be applied to OSPFv3. Three sub-TLVs: Link ID, 67 Local interface IP address and Remote interface IP address can't be 68 used for OSPFv3. To make it applicable three new sub-TLVs are 69 defined. 71 9 - Neighbor ID (8 octets) 72 10 - Local Interface IPv6 Address (16N octets) 73 11 - Remote Interface IPv6 Address (16N octets) 75 3.1 Neighbor ID 77 In OSPFv2, Link ID is unique key to identify Network LSA. In OSPFv3 78 to identify Network LSA, the combination of Neighbor Interface ID and 79 Neighbor Router ID is needed. So new sub-TLV Neighbor ID is defined. 81 The Neighbor ID sub-TLV is TLV type 9, and is 8 octets in length. It 82 contains 4 octet Neighbor Interface ID following 4 octet Neighbor 83 Router ID. Neighbor Interface ID and Neighbor Router ID value is 84 same as described in [OSPFV3] A.4.3 Router-LSAs. 86 3.2 Local Interface IPv6 Address 88 The Local Interface IPv6 Address sub-TLV specifies the IPv6 89 address(es) of the interface corresponding to this link. If there 90 are multiple local addresses on the link, they are all listed in this 91 sub-TLV. Link-local address should not be included in this sub-TLV. 93 The Local Interface IPv6 Address sub-TLV is TLV type 10, and is 16N 94 octets in length, where N is the number of local addresses. 96 3.3 Remote Interface IPv6 Address 98 The Remote Interface IPv6 Address sub-TLV specifies the IPv6 99 address(es) of the neighbor's interface corresponding to this link. 100 This and the local address are used to discern multiple parallel 101 links between systems. If the Link Type of the link is Multiaccess, 102 the Remote Interface IPv6 Address is set to ::. Link-local address 103 should not be included in this sub-TLV. 105 The Remote Interface IPv6 Address sub-TLV is TLV type 11, and is 16N 106 octets in length, where N is the number of neighbor addresses. 108 4. Traffic-Engineering-LSA 110 New LS type Traffic-Engineering-LSA is defined as Area scope LSA. 112 LSA function code LS Type Description 113 -------------------------------------------------------------------- 114 10 0x200a Traffic-Engineering-LSA 116 5. Security Considerations 118 Security issues are not discussed in this memo. 120 6. Reference 122 [RFC2702] RFC 2702, "Requirements for Traffic Engineering Over 123 MPLS," D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, 124 and J. McManus, September 1999. 126 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 128 [RFC2740] R. Coltun, D. Ferguson, J.Moy, "OSPF for IPv6", RFC2740, 129 December 1999. 131 [OSPFV2-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 132 Extensions to OSPF", 133 draft-katz-yeung-ospf-traffic-08.txt, work in progress. 135 7. Author's Address 137 Kunihiro Ishiguro 138 IP Infusion Inc. 139 111 W. St. John Street, Suite 910 140 San Jose CA 95113 141 e-mail: kunihiro@ipinfusion.com 143 Toshiaki Takada 144 IP Infusion Inc. 145 111 W. St. John Street, Suite 910 146 San Jose CA 95113 147 e-mail: takada@ipinfusion.com