idnits 2.17.1 draft-nalawade-kapoor-tunnel-safi-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: ---------------------------------------------------------------------------- == 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 69: '...P SSA Attribute, MUST contain at least...' RFC 2119 keyword, line 70: '...odes for this SAFI. It MAY contain one...' RFC 2119 keyword, line 116: '...ue contained in this Length field MUST...' RFC 2119 keyword, line 123: '... the information SHOULD take the sende...' RFC 2119 keyword, line 187: '...ue contained in this Length field MUST...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Length A 2 Octet field that specifies the length of the L2TPv3 attribute in octets. The value contained in this Length field MUST not exceed the total length of the BGP SSA [SSA] Attribute minus the total length of any prior TLVs. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Length A 2 Octet field that specifies the length of the mGRE information in octets. The value contained in this Length field MUST not exceed the total length of the BGP SSA [SSA] Attribute minus the total length of any prior TLVs. -- 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: 'SSA' is mentioned on line 245, but not defined == Missing Reference: 'BGP-MP' is mentioned on line 233, but not defined == Unused Reference: 'BGP-4' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'BGP-CAP' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'MULTI-BGP' is defined on line 282, but no explicit reference was found in the text == Unused Reference: 'IPSEC-ARCH' is defined on line 285, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AFI' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-SAFI' == Outdated reference: A later version (-26) exists of draft-ietf-idr-bgp4-17 -- Unexpected draft version: The latest known version of draft-ietf-idr-rfc2842bis is -01, but you're referring to -02. -- No information found for draft-nalawade-kapoor-bgp-ssa - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BGP-SSA' == Outdated reference: A later version (-10) exists of draft-ietf-idr-rfc2858bis-02 ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC-ARCH') (Obsoleted by RFC 4301) Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Gargi Nalawade 3 Internet Draft Ruchi Kapoor 4 Expires: December 2003 Dan Tappan 6 Cisco Systems 8 IPv4-Tunnel SAFI 10 draft-nalawade-kapoor-tunnel-safi-00.txt 12 1. 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 2. Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 3. Abstract 39 There is a need for Tunnel end-point discovery within and across 40 Autonomous Systems. BGP is the only protocol that is widely-spoken 41 across Autonomous Systems and can carry this information. This 42 document defines how BGP speakers can convey Tunnel end-point 43 reachability information. 45 4. Introduction 46 Two end-points of a Tunnel need to know the end-point information and 47 its binding to a network address at the remote point. Normally, this 48 can be statically shared and configured. But in case of a large 49 network where there may be a need for a large number of tunnels, the 50 number of tunnel end-points that need to be exchanged and maintained, 51 grows. It then needs to be exchanged and maintained using an inter-AS 52 protocol. 54 5. The IPv4-Tunnel SAFI 56 This document defines a new SAFI called the IPv4-Tunnel SAFI. The 57 [IANA-AFI] [IANA-SAFI] value pair used to identify this 58 SAFI is (AFI=1, SAFI=TBD). 60 The tunnel end point address will be carried as an NLRI in the 61 MP_REACH attribute for this SAFI. The NLRI Format will be a 2-byte 62 Reserved field followed by a 4-byte IPv4 address. 64 6. BGP Attribute 66 The BGP SSA Attribute [BGP-SSA] will be used to carry the Tunnel 67 end-point information. 69 The Value Field of the BGP SSA Attribute, MUST contain at least one 70 of the following valid Type codes for this SAFI. It MAY contain one 71 or more TLVs with these Type codes. 73 Type 1: L2TPv3 Tunnel information 75 Type 2: mGRE Tunnel information 77 Type 3: IPSec Tunnel information 79 Type 4: MPLS Tunnel information 81 6.1. L2TPv3 Tunnel information TLV 83 The L2TPv3 Tunnel Information TLV has a type of 1. The value part of 84 the L2TPv3 Tunnel Information Type contains the following : 86 - Preference (2 Octets) 87 - Flags (1 Octet) 88 - Cookie Length (1 Octet) 89 - Session ID (4 Octets) 90 - Cookie (Variable) 92 The L2TPv3 Tunnel Information TLV looks as follows : 94 0 1 95 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | Type = 0x01 | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | Length (2 octets) | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | Preference (2 octets) | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 |S| Flags | Cookie Length | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Session ID (4 Octets) | 106 | | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | | 109 | Cookie (Variable) | 110 | | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 where 115 Length A 2 Octet field that specifies the length of the L2TPv3 116 attribute in octets. The value contained in this Length field MUST 117 not exceed the total length of the BGP SSA [SSA] Attribute minus the 118 total length of any prior TLVs. 120 Preference A 2 Octet field containing a Preference associated with 121 the TLV. The Preference value indicates a preferred ordering of 122 tunneling encapsulations according to the sender. The recipient of 123 the information SHOULD take the sender's preference into account in 124 selecting which encapsulation it will use. A higher value indicates a 125 higher preference. 127 Flags A 1 Octet field containing flag-bits. The leftmost bit 128 indicates whether Sequence numbering is to be used or not. The 129 remaining bits are reserved for future use. 131 Cookie Length Cookie Length is a 1 Octet field that contains the 132 length of the Variable length Cookie. 134 Session ID A 4 Octet field containing a non-zero identifier for a 135 session. 137 Cookie Cookie is a variable length (maximum 64 bits), value used by 138 L2TPv3 to check the association of a received data message with the 139 session identified by the Session ID. 141 The default value of the Length Field for the L2TPv3 Tunnel 142 information TLV is between 8 and 16 bytes, depending on the length of 143 the Cookie field specified in Cookie length. If the length of the TLV 144 is greater than that value, the subsequent portion of the Value field 145 contains one or more sub-TLVs. 147 A Sub-TLV when present is of the following format : 149 0 1 150 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Sub-Type | Length | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Value (Variable) | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 where Sub-Type & Length are of 1-Octet each & the Value field is 158 variable as specified by the Length. 160 6.2. mGRE Tunnel Information TLV 162 The mGRE Tunnel Information Type has a Type 2. The value part of the 163 mGRE Tunnel Information Type contains the following : 165 - Preference (2 Octets) 166 - Flags (1 Octet) 167 - mGRE Key (0 or 4 Octets) 169 The mGRE Tunnel Information TLV looks as follows : 171 0 1 172 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Type = 0x02 | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Length (2 octets) | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Preference (2 octets) | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 |S|K| Flags | | 181 +-+-+-+-+-+-+-+-+ | 182 | mGRE Key (4 Octets) | 183 | | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Length A 2 Octet field that specifies the length of the mGRE 187 information in octets. The value contained in this Length field MUST 188 not exceed the total length of the BGP SSA [SSA] Attribute minus the 189 total length of any prior TLVs. 191 Preference A 2 Octet field containing a Preference associated with 192 the TLV. The Preference value indicates a preferred ordering of 193 tunneling encapsulations according to the sender. The recipient of 194 the information SHOULD take the sender's preference into account in 195 selecting which encapsulation it will use. A higher value indicates a 196 higher preference. 198 Flags A 1 Octet field containing flag-bits. The leftmost bit 199 indicates whether Sequence numbering is to be used or not. The 2nd 200 bit indicates whether an mGRE Key is present or not. The remaining 201 bits are reserved for future use. 203 mGRE Key A 4 Octet field containing an optional mGRE Key. 205 If the Length field of the TLV contains a value greater than 3 Octets 206 plus the value specified in the Key Length, the subsequent portion of 207 the Value field contains one or more sub-TLVs. 209 A Sub-TLV when present is of the following format : 211 0 1 212 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Sub-Type | Length | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Value (Variable) | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 where Sub-Type & Length are of 1-Octet each & the Value field is 220 variable as specified by the Length. 222 6.3. IPSec Tunnel Information TLV 223 The IPSec Tunnel Information Type has a Type 3. The format of the 224 IPSec Tunnel Information TLV is TBD. 226 6.4. MPLS TLV 228 The MPLS TLV has a Type 4. The format of the MPLS TLV is TBD. 230 7. Capability Advertisement 232 A BGP speaker that wishes to exchange the IPv4-Tunnel SAFI, MUST use 233 the MP_EXT Capability Code as defined in [BGP-MP], to advertise the 234 corresponding (AFI, SAFI) pair. 236 A BGP speaker MAY participate in the distribution of IPv4-Tunnel 237 information. 239 8. Operation 241 A BGP Speaker that receives the Capability for the IPv4-Tunnel SAFI, 242 MAY advertise the IPv4-Tunnel prefixes to that peer. 244 In the UPDATE message for this SAFI sent to a peer, a BGP speaker 245 MUST only advertise the SAFI-specific attribute [SSA] TLVs that are 246 defined as valid for this SAFI. 248 If a BGP Speaker receives an SSA TLV that it does not recognize, it 249 will accept it and propagate it to other peers. 251 9. Deployment Considerations 253 In order for the Tunnels to come up between two end-points, the BGP 254 Speakers advertising the Tunnel end-points using the Ipv4 Tunnel 255 SAFI, MUST exchange at least one common encapsulation option. 257 10. Security Considerations 259 This extension to BGP does not change the underlying security issues. 261 11. Acknowledgements 263 We would like to thank Jim Guichard, Arjun Sreekantiah, Shyam Suri, 264 Chandrashekhar Appanna, John Scudder and Mark Townsley for their 265 comments and suggestions. 267 12. References 269 [IANA-AFI] http://www.iana.org/assignments/address-family-numbers 271 [IANA-SAFI] http://www.iana.org/assignments/safi-namespace 273 [BGP-4] Rekhter, Y. and T. Li (editors), "A Border Gateway Protocol 274 4 (BGP-4)", Internet Draft draft-ietf-idr-bgp4-17.txt, January 2002. 276 [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with 277 BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002. 279 [BGP-SSA] Kapoor R., Nalawade G., "BGPv4 SAFI-Specific Attribute", 280 draft-nalawade-kapoor-bgp-ssa-00.txt, work in progress. 282 [MULTI-BGP] Bates et al, Multiprotocol Extensions for BGP-4, draft- 283 ietf-idr-rfc2858bis-02.txt, work in progress. 285 [IPSEC-ARCH] Kent, S., and R. Atkinson, "Security Architecture for 286 the Internet Protocol", RFC 2401, November 1998. 288 13. Author's Addresses 290 Gargi Nalawade 291 Cisco Systems, Inc 292 170 West Tasman Drive 293 San Jose, CA 95134 294 mailto:gargi@cisco.com 296 Ruchi Kapoor 297 Cisco Systems, Inc 298 170 West Tasman Drive 299 San Jose, CA 95134 300 mailto:ruchi@cisco.com 302 Dan Tappan 303 Cisco Systems, Inc 304 170 West Tasman Drive 305 San Jose, CA 95134 306 mailto:tappan@cisco.com 308 14. Intellectual Property Statement 310 The IETF takes no position regarding the validity or scope of any 311 intellectual property or other rights that might be claimed to 312 pertain to the implementation or use of the technology described in 313 this document or the extent to which any license under such rights 314 might or might not be available; neither does it represent that it 315 has made any effort to identify any such rights. Information on the 316 IETF's procedures with respect to rights in standards-track and 317 standards- related documentation can be found in BCP-11. Copies of 318 claims of rights made available for publication and any assurances of 319 licenses to be made available, or the result of an attempt made to 320 obtain a general license or permission for the use of such 321 proprietary rights by implementers or users of this specification can 322 be obtained from the IETF Secretariat. 324 The IETF invites any interested party to bring to its attention any 325 copyrights, patents or patent applications, or other proprietary 326 rights which may cover technology that may be required to practice 327 this standard. Please address the information to the IETF Executive 328 Director. 330 15. Full Copyright Statement 332 Copyright (C) The Internet Society (2001). All Rights Reserved. 334 This document and translations of it may be copied and furnished to 335 others, and derivative works that comment on or otherwise explain it 336 or assist in its implementation may be prepared, copied, published 337 and distributed, in whole or in part, without restriction of any 338 kind, provided that the above copyright notice and this paragraph are 339 included on all such copies and derivative works. However, this 340 document itself may not be modified in any way, such as by removing 341 the copyright notice or references to the Internet Society or other 342 Internet organizations, except as needed for the purpose of 343 developing Internet standards in which case the procedures for 344 copyrights defined in the Internet Standards process must be 345 followed, or as required to translate it into languages other than 346 English. The limited permissions granted above are perpetual and 347 will not be revoked by the Internet Society or its successors or 348 assigns. This document and the information contained herein is 349 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 350 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 351 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 352 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 353 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 355 16. Expiration Date 357 This memo is filed as , and 358 expires December, 2003.