idnits 2.17.1 draft-ietf-ospf-te-node-addr-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 02, 2009) is 5252 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Aggarwal 3 Internet Draft Juniper Networks 4 Expiration Date: June 2010 5 K. Kompella 6 Juniper Networks 8 December 02, 2009 10 Advertising a Router's Local Addresses in OSPF TE Extensions 12 draft-ietf-ospf-te-node-addr-07.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright and License Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 This document may contain material from IETF Documents or IETF 46 Contributions published or made publicly available before November 47 10, 2008. The person(s) controlling the copyright in some of this 48 material may not have granted the IETF Trust the right to allow 49 modifications of such material outside the IETF Standards Process. 50 Without obtaining an adequate license from the person(s) controlling 51 the copyright in such materials, this document may not be modified 52 outside the IETF Standards Process, and derivative works of it may 53 not be created outside the IETF Standards Process, except to format 54 it for publication as an RFC or to translate it into languages other 55 than English. 57 Abstract 59 OSPF Traffic Engineering (TE) extensions are used to advertise TE 60 Link State Advertisements (LSAs) containing information about TE- 61 enabled links. The only addresses belonging to a router that are 62 advertised in TE LSAs are the local addresses corresponding to TE- 63 enabled links, and the local address corresponding to the Router ID. 65 In order to allow other routers in a network to compute Multiprotocol 66 Label Switching (MPLS) traffic engineered Label Switched Paths (TE 67 LSPs) to a given router's local addresses, those addresses must also 68 be advertised by OSPF TE. 70 This document describes procedures that enhance OSPF TE to advertise 71 a router's local addresses. 73 Table of Contents 75 1 Specification of requirements ......................... 3 76 2 Introduction .......................................... 3 77 2.1 Motivation ............................................ 3 78 3 Rejected Potential Solution ........................... 4 79 4 Solution .............................................. 4 80 4.1 Node Attribute TLV .................................... 5 81 4.2 Operation ............................................. 6 82 5 Security Considerations ............................... 7 83 6 IANA Considerations ................................... 7 84 7 Acknowledgements ...................................... 7 85 8 References ............................................ 8 86 8.1 Normative References .................................. 8 87 8.2 Informative References ................................ 8 88 9 Authors' Addresses .................................... 8 90 1. Specification of requirements 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. Introduction 98 2.1. Motivation 100 In some cases it is desirable to set up constrained shortest path 101 first (CSPF) computed Multiprotocol Label Switching (MPLS) Traffic 102 Engineered Label Switched Paths (TE LSPs) to local addresses of a 103 router, that are not currently advertised in the TE LSAs i.e., 104 loopback and non-TE interface addresses. 106 For instance, in a network carrying VPN and non-VPN traffic, it is 107 often desirable to use different MPLS TE LSPs for the VPN traffic and 108 the non-VPN traffic. In this case one loopback address may be used as 109 the BGP next-hop for VPN traffic while another may be used as the BGP 110 next-hop for non-VPN traffic. It is also possible that different BGP 111 sessions are used for VPN and non-VPN services. Hence two separate 112 MPLS TE LSPs are desirable, one to each loopback address. 114 However, current routers in an OSPF network can only use CSPF to 115 compute MPLS TE LSPs to the router ID or the local addresses of a 116 remote router's TE enabled links. This restriction arises because 117 OSPF TE extensions [RFC3630, RFC5329] only advertise the router ID 118 and the local addresses of TE enabled links of a given router. Other 119 routers in the network can populate their traffic engineering 120 database (TED) with these local addresses belonging to the 121 advertising router. However, they cannot populate the TED with the 122 advertising router's other local addresses, i.e., loopback and non-TE 123 interface addresses. OSPFv2 stub links in the router LSA [RFC2328], 124 provide stub reachability information to the router but are not 125 sufficient to learn all the local addresses of a router. In 126 particular for a subnetted point-to-point (P2P) interface the stub 127 link ID is the subnet address. While for a non-subnetted interface 128 the stub link ID is the neighbor address. Intra-prefix LSAs in 129 OSPFv3 [RFC5340] are also not sufficient to learn the local 130 addresses. 132 For the above reasons this document defines an enhancement to OSPF TE 133 extensions to advertise the local addresses of a node. 135 3. Rejected Potential Solution 137 A potential solution would be to advertise a TE link TLV for each 138 local address, possibly with a new link type. However, this is 139 inefficient since the only meaningful information is the address. 140 Furthermore, this would require implementations to process these TE 141 link TLVs differently from others; for example, the TE metric is 142 normally considered a mandatory sub-TLV, but would have no meaning 143 for a local address. 145 4. Solution 147 The solution is to advertise the local addresses of a router in a new 148 OSPF TE LSA node attribute TLV. It is anticipated that the node 149 attribute TLV will also prove more generally useful. 151 4.1. Node Attribute TLV 153 The node attribute TLV carries the attributes associated with a 154 router. The TLV type is TBD and the length is variable. It contains 155 one or more sub-TLVs. This document defines the following sub-TLVs: 157 1. Node IPv4 Local Address sub-TLV 158 2. Node IPv6 Local Address sub-TLV 160 The node IPv4 local address sub-TLV has a type of 1 and contains one 161 or more local IPv4 addresses. It has the following format: 163 0 1 2 3 164 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | 1 | Length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Prefix Len 1 | IPv4 Prefix 1 | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 |Prefix 1 cont. | : 171 +-+-+-+-+-+-+-+-+ ~ 172 : . : 173 ~ . +-+-+-+-+-+-+-+-+ 174 : . | Prefix Len n | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | IPv4 Prefix n | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Each local IPv4 address is encoded as a 180 tuple. Prefix Length is encoded in 1 byte. It is the number of bits 181 in the Address and can be at most 32. Prefix is an IPv4 address 182 prefix and is encoded in 4 bytes with zero bits as necessary. 184 The Node IPv4 Local Address sub-TLV length is in octets. It is the 185 sum of the lengths of all n IPv4 Address encodings in the sub-TLV 186 where n is the number of local addresses included in the sub-TLV. 188 The node IPv6 local address sub-TLV has a type of 2 and contains one 189 or more local IPv6 addresses. It has the following format: 191 0 1 2 3 192 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | 2 | Length | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Prefix Len 1 | Prefix 1 Opt. | IPv6 Prefix 1 | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | IPv6 Prefix 1 cont. : 200 : . ~ 201 ~ . 202 : . 203 : +-+-+-+-+-++-+-+-+-+-++-+-+-+-+-+ 204 : | Prefix Len n | Prefix n Opt. | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | IPv6 Prefix n : 207 | : 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-- 210 Each local IPv6 address is encoded using the procedures in [RFC5340]. 211 Each IPv6 address MUST be represented by a combination of three 212 fields: PrefixLength, PrefixOptions, and Address Prefix. PrefixLength 213 is the length in bits of the prefix and is an 8 bit field. 214 PrefixOptions is an 8-bit field describing various capabilities 215 associated with the prefix [RFC5340]. Address Prefix is an encoding 216 of the prefix itself as an even multiple of 32-bit words, padding 217 with zero bits as necessary. This encoding consumes (PrefixLength + 218 31) / 32) 32-bit words. 220 The Node IPv6 Local Address sub-TLV length is in octets. It is the 221 sum of the lengths of all n IPv6 Address encodings in the sub-TLV 222 where n is the number of local addresses included in the sub-TLV. 224 4.2. Operation 226 A router announces one or more local addresses in the node attribute 227 TLV. The local addresses that can be learned from TE LSAs i.e., 228 router address and TE interface addresses SHOULD NOT be advertised in 229 the node local address sub-TLV. The local addresses advertised will 230 depend on the local configuration of the advertising router. The 231 default behavior MAY be to advertise all the loopback interface 232 addresses. 234 The node attribute TLV MUST NOT appear in more than one TE LSA 235 originated by a router. Furthermore, such a LSA MUST NOT include more 236 than one node attribute TLV. A node attribute TLV MUST NOT carry more 237 than one Node IPv4 Local Address sub-TLV. A node attribute TLV MUST 238 NOT carry more than one Node IPv6 Local Address sub-TLV. 240 5. Security Considerations 242 This document does not introduce any further security issues other 243 than those discussed in [RFC3630, RFC5329]. 245 6. IANA Considerations 247 The Node Attribute TLV type has to be IANA assigned from the range 3 248 - 32767 as specified in [RFC3630], from the top level types in TE 249 LSAs registry maintained by IANA at [IANA-OSPF-TE]. 251 IANA is requested to maintain the registry for the sub-TLVs of the 252 node attribute TLV and reserve value 1 for Node IPv4 Local Address 253 sub-TLV and value 2 for Node IPv6 Local Address sub-TLV. 255 The guidelines for the assignment of types for sub-TLVs of the node 256 attribute TLV are as follows: 258 o Types in the range 3-32767 are to be assigned via Standards 259 Action. 261 o Types in the range 32768-32777 are for experimental use; these 262 will not be registered with IANA, and MUST NOT be mentioned by 263 RFCs. 265 o Types in the range 32778-65535 are not to be assigned at this 266 time. Before any assignments can be made in this range, there 267 MUST be a Standards Track RFC that specifies IANA 268 Considerations that covers the range being assigned. 270 7. Acknowledgements 272 We would like to thank Nischal Sheth for his contribution to this 273 work. We would also like to thank Jean Philippe Vasseur, Acee Lindem, 274 Venkata Naidu, Dimitri Papadimitriou and Adrian Farrel for their 275 comments. 277 8. References 279 8.1. Normative References 281 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, March 1997. 286 [RFC3630] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering 287 Extensions to OSPF version 2", RFC 3630, 288 September 2003. 290 [RFC5340] R. Coltun, et. al.,"OSPF for IPv6", RFC 5340. 292 8.2. Informative References 294 [RFC5329] K. Ishiguro, T. Takada, "Traffic Engineering 295 Extensions to OSPF version 3", RFC 5329 297 [IANA-OSPF-TE] http://www.iana.org/assignments/ospf-traffic-eng-tlvs 299 9. Authors' Addresses 301 Rahul Aggarwal 302 Juniper Networks 303 1194 North Mathilda Ave. 304 Sunnyvale, CA 94089 306 Phone: +1-408-936-2720 307 Email: rahul@juniper.net 309 Kireeti Kompella 310 Juniper Networks 311 1194 North Mathilda Ave. 312 Sunnyvale, CA 94089 313 Email: kireeti@juniper.net