idnits 2.17.1 draft-raggarwa-ospf-te-node-addr-00.txt: ** The Abstract section seems to be numbered 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'OSPFv2' is mentioned on line 65, but not defined == Unused Reference: 'OSPF' is defined on line 160, but no explicit reference was found in the text == Unused Reference: 'RFC' is defined on line 162, but no explicit reference was found in the text == Unused Reference: 'OSPF-TE-MESH' is defined on line 176, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2740 (ref. 'OSPFv3') (Obsoleted by RFC 5340) == Outdated reference: A later version (-13) exists of draft-ietf-ospf-ospfv3-traffic-01 -- Possible downref: Normative reference to a draft: ref. 'OSPF-TE-MESH' Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Rahul Aggarwal 3 Internet Draft Kireeti Kompella 4 Expiration Date: March 2004 Juniper Networks 6 Advertising a Router's Local Addresses in OSPF TE Extensions 8 draft-raggarwa-ospf-te-node-addr-00.txt 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2. Abstract 33 This document describes procedures that enhance OSPF Traffic 34 Engineering (TE) extensions for advertising a router's local 35 addresses. This is needed to enable other routers in a network to 36 compute traffic engineered MPLS LSPs to a given router's local 37 addresses. Currently, the only addresses belonging to a router that 38 are advertised in TE LSAs are the router's local addresses on links 39 enabled for TE, and the Router ID. 41 3. Motivation 43 In some cases it is desirable to setup, constrained shortest path 44 first (CSPF) computed MPLS TE LSPs, to local addresses of a router 45 that are not currently advertised in the TE LSAs i.e. loopback and 46 non-TE interface addresses. 48 For instance in a network carrying VPN and non-VPN traffic, its often 49 desirable to use different MPLS TE LSPs for the VPN traffic and the 50 non-VPN traffic. In this case one loopback address may be used as the 51 BGP next-hop for VPN traffic while another may be used as the BGP 52 next-hop for non-VPN traffic. Its also possible that different BGP 53 sessions are used for VPN and non-VPN services. Hence two separate 54 MPLS TE LSPs are desirable, one to each loopback address. 56 However currently routers in an OSPF network can only use CSPF to 57 compute MPLS TE LSPs to the router ID or the local addresses of TE 58 enabled links, of a remote router. This restriction arises because 59 OSPF TE extensions [OSPF-TE, OSPFv3-TE] only advertise the router ID 60 and the local addresses of TE enabled links, of a given router. Other 61 routers in the network can populate their traffic engineering 62 database (TED) with these local addresses belonging to the 63 advertising router. However they cannot populate the TED with other 64 local addresses of the advertising router i.e. loopback and non-TE 65 interface addresses. OSPFv2 stub links in the router LSA [OSPFv2], 66 provide stub reachability information to the router but are not 67 sufficient to learn all the local addresses of a router. The same 68 problem exists with intra-prefix LSAs in OSPFv3 [OSPFv3]. 70 For the above reasons this document proposes an enhancement to OSPF 71 TE extensions to advertise the local addresses of a node. 73 4. A Potential Solution 75 A potential solution would be to advertise a TE link TLV for each 76 local address, possibly with a new link type. However, this is 77 inefficient, as the only meaningful information is the address. 78 Furthermore, this would require implementations to process these TE 79 link TLVs differently from others; for example, the TE metric is 80 normally considered a mandatory sub-TLV, but would have no meaning 81 for a local address 83 5. Proposed Solution 85 The proposed solution is to advertise the local addresses of a router 86 in a new node attribute TLV, in the OSPF TE LSA. It is anticipated 87 that a node attribute TLV will also prove more generally useful. 89 5.1. Node Attribute TLV 91 The node attribute TLV carries the attributes associated with a 92 router. The TLV type is TBD and the length is variable. It contains 93 one or more sub-TLVs. This document defines the following sub-TLVs: 95 1. Node IPv4 Local Address sub-TLV 96 2. Node IPv6 Local Address sub-TLV 98 The node IPv4 local address sub-TLV has a type of 1 and contains one 99 or more local IPv4 addresses. It has the following format: 101 0 1 2 3 102 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 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | 1 | Length | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | IPv4 Address 1 | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 . . . 109 . . . 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | IPv4 Address n | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 The length is set to 4 * n where n is the number of local addresses 115 included in the sub-TLV. 117 The node IPv6 local address sub-TLV has a type of 2 and contains one 118 or more local IPv6 addresses. It has the following format: 120 0 1 2 3 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | 2 | Length | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | IPv6 Address 1 | 126 | | 127 | | 128 | | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 . . . 131 . . . 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | IPv6 Address n | 134 | | 135 | | 136 | | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-- 139 The length is set to 16 * n where n is the number of local addresses 140 included in the sub-TLV. 142 6. Security Considerations 144 This document does not introduce any further security issues other 145 than those discussed in [OSPF-TE, OSPFv3-TE]. 147 7. IANA Considerations 149 The Node Attribute TLV type has to be IANA assigned from the range 3 150 - 32767 as specified in [OSPF-TE]. 152 8. Acknowledgments 154 We would like to thank Nischal Sheth for his contribution to this 155 work. We woud also like to thank Jean Philippe Vasseur for his 156 comments. 158 9. References 160 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 162 [RFC] Bradner, S., "Key words for use in RFCs to Indicate 163 Requirement Levels", BCP 14, RFC 2119, March 1997. 165 [OSPF-TE] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering 166 Extensions to OSPF version 2", RFC 3630, 167 September 2003. 169 [OSPFv3] R. Coltun, D. Ferguson, J. Moy, "OSPF for IPv6", 170 RFC 2740. 172 [OSPFv3-TE] K. Ishiguro, T. Takada, "Traffic Engineering 173 Extensions to OSPF version 3", 174 draft-ietf-ospf-ospfv3-traffic-01.txt. 176 [OSPF-TE-MESH] J. P. Vasseur, P. Psenak, "OSPF Traffic Engineering 177 Capability TLVs", 178 draft-vasseur-mpls-ospf-te-cap-00.txt. 180 10. Author Information 182 Rahul Aggarwal 183 Juniper Networks 184 1194 North Mathilda Ave. 185 Sunnyvale, CA 94089 186 Email: rahul@juniper.net 188 Kireeti Kompella 189 Juniper Networks 190 1194 North Mathilda Ave. 191 Sunnyvale, CA 94089 192 Email: kireeti@juniper.net