idnits 2.17.1 draft-nalawade-kapoor-tunnel-safi-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 346. ** Found boilerplate matching RFC 3979, Section 5, paragraph 3 (on line 346), which is fine, but *also* found old RFC 2026, Section 10.4B text on line 340. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 4) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 78: '...P SSA Attribute, MUST contain at least...' RFC 2119 keyword, line 79: '...odes for this SAFI. It MAY contain one...' RFC 2119 keyword, line 124: '...ue contained in this Length field MUST...' RFC 2119 keyword, line 131: '... the information SHOULD take the sende...' RFC 2119 keyword, line 196: '...ue contained in this Length field MUST...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3979, Section 5, paragraph 3 boilerplate, a section with a similar start was also found: The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. == 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 [BGP-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 [BGP-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: 'BGP-MP' is mentioned on line 243, but not defined == Unused Reference: 'BGP-CAP' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'MULTI-BGP' is defined on line 292, 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-22 -- 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 -- Unexpected draft version: The latest known version of draft-nalawade-bgp-update-v2 is -00, but you're referring to -01. (However, the state information for draft-nalawade-kapoor-bgp-ssa is not up-to-date. The last update was unsuccessful) -- Possible downref: Normative reference to a draft: ref. 'BGP-UPDATEv2' Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Gargi Nalawade 2 Internet Draft Ruchi Kapoor 3 Expires: April 2005 Dan Tappan 5 Cisco Systems 7 Tunnel SAFI 9 draft-nalawade-kapoor-tunnel-safi-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he is aware have been 15 or will be disclosed, and any of which he becomes aware will be 16 disclosed, in accordance with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 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 Abstract 36 There is a need for Tunnel end-point discovery within and across 37 Autonomous Systems. BGP is the only protocol that is widely-spoken 38 across Autonomous Systems and can carry this information. This 39 document defines how BGP speakers can convey Tunnel end-point 40 reachability information. 42 1. Introduction 44 Two end-points of a Tunnel need to know the end-point information and 45 its binding to a network address at the remote point. Normally, this 46 can be statically shared and configured. But in case of a large 47 network where there may be a need for a large number of tunnels, the 48 number of tunnel end-points that need to be exchanged and maintained, 49 grows. It then needs to be exchanged and maintained using an inter-AS 50 protocol. 52 2. The Tunnel SAFI 54 This document defines a new SAFI called the Tunnel SAFI. The [IANA-AFI] [IANA-SAFI] value pair used to identify this SAFI is 56 (AFI=1, SAFI=TBD) for the IPv4 AFI and (AFI=2, SAFI=TBD) for the IPv6 57 AFI. 59 For BGP Speakers supporting [BGP-4], the tunnel end point address 60 will be carried as an NLRI in the MP_REACH attribute for this SAFI. 61 For BGP Speakers suppprting [BGP-UPDATEv2], the tunnel end point 62 address will be carried as an NLRI in the NLRI section of the BGP 63 Updatev2 message. 65 The NLRI will be encoded as a 2-octet Identifier followed by the NLRI 66 format as specified by the respective AFI. The Identifier will 67 contain a 2-octet Identifier that identifies the Tunnel end point 68 being advertised. This Identifier enables multiple Tunnel end-points 69 to share the same network address, thus conserving the number of 70 addresses needed to be configured by the operator on each of the 71 Tunnel-endpoints. 73 3. BGP Attribute 75 The BGP SSA Attribute [BGP-SSA] will be used to carry the Tunnel 76 end-point information. 78 The Value Field of the BGP SSA Attribute, MUST contain at least one 79 of the following valid Type codes for this SAFI. It MAY contain one 80 or more TLVs with these Type codes. 82 Type 1: L2TPv3 Tunnel information 84 Type 2: mGRE Tunnel information 86 Type 3: IPSec Tunnel information 88 Type 4: MPLS Tunnel information 90 3.1. L2TPv3 Tunnel information TLV 91 The L2TPv3 Tunnel Information TLV has a type of 1. The value part of 92 the L2TPv3 Tunnel Information Type contains the following : 94 - Preference (2 Octets) 95 - Flags (1 Octet) 96 - Cookie Length (1 Octet) 97 - Session ID (4 Octets) 98 - Cookie (Variable) 100 The L2TPv3 Tunnel Information TLV looks as follows : 102 0 1 103 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Type = 0x01 | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Length (2 octets) | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Preference (2 octets) | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 |S| Flags | Cookie Length | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Session ID (4 Octets) | 114 | | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | | 117 | Cookie (Variable) | 118 | | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 where 123 Length A 2 Octet field that specifies the length of the L2TPv3 124 attribute in octets. The value contained in this Length field MUST 125 not exceed the total length of the BGP SSA [BGP-SSA] Attribute minus 126 the total length of any prior TLVs. 128 Preference A 2 Octet field containing a Preference associated with 129 the TLV. The Preference value indicates a preferred ordering of 130 tunneling encapsulations according to the sender. The recipient of 131 the information SHOULD take the sender's preference into account in 132 selecting which encapsulation it will use. A higher value indicates a 133 higher preference. 135 Flags A 1 Octet field containing flag-bits. The leftmost bit 136 indicates whether Sequence numbering is to be used or not. The 137 remaining bits are reserved for future use. 139 Cookie Length Cookie Length is a 1 Octet field that contains the 140 length of the Variable length Cookie. 142 Session ID A 4 Octet field containing a non-zero identifier for a 143 session. 145 Cookie Cookie is a variable length (maximum 64 bits), value used by 146 L2TPv3 to check the association of a received data message with the 147 session identified by the Session ID. 149 The default value of the Length Field for the L2TPv3 Tunnel 150 information TLV is between 8 and 16 bytes, depending on the length of 151 the Cookie field specified in Cookie length. If the length of the TLV 152 is greater than that value, the subsequent portion of the Value field 153 contains one or more sub-TLVs. 155 A Sub-TLV when present is of the following format : 157 0 1 158 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Sub-Type | Length | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Value (Variable) | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 where Sub-Type & Length are of 1-Octet each & the Value field is 166 variable as specified by the Length. 168 3.2. mGRE Tunnel Information TLV 170 The mGRE Tunnel Information Type has a Type 2. The value part of the 171 mGRE Tunnel Information Type contains the following : 173 - Preference (2 Oc 174 tets) 175 - Flags (1 Octet) 176 - mGRE Key (0 or 4 Octets) 178 The mGRE Tunnel Information TLV looks as follows : 180 0 1 181 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Type = 0x02 | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Length (2 octets) | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Preference (2 octets) | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 |S|K| Flags | | 190 +-+-+-+-+-+-+-+-+ | 191 | mGRE Key (4 Octets) | 192 | | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Length A 2 Octet field that specifies the length of the mGRE 196 information in octets. The value contained in this Length field MUST 197 not exceed the total length of the BGP SSA [BGP-SSA] Attribute minus 198 the total length of any prior TLVs. 200 Preference A 2 Octet field containing a Preference associated with 201 the TLV. The Preference value indicates a preferred ordering of 202 tunneling encapsulations according to the sender. The recipient of 203 the information SHOULD take the sender's preference into account in 204 selecting which encapsulation it will use. A higher value indicates a 205 higher preference. 207 Flags A 1 Octet field containing flag-bits. The leftmost bit 208 indicates whether Sequence numbering is to be used or not. The 2nd 209 bit indicates whether an mGRE Key is present or not. The remaining 210 bits are reserved for future use. 212 mGRE Key A 4 Octet field containing an optional mGRE Key. 214 If the Length field of the TLV contains a value greater than 3 Octets 215 plus the value specified in the Key Length, the subsequent portion of 216 the Value field contains one or more sub-TLVs. 218 A Sub-TLV when present is of the following format : 220 0 1 221 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Sub-Type | Length | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Value (Variable) | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 where Sub-Type & Length are of 1-Octet each & the Value field is 229 variable as specified by the Length. 231 3.3. IPSec Tunnel Information TLV 233 The IPSec Tunnel Information Type has a Type 3. The format of the 234 IPSec Tunnel Information TLV is TBD. 236 3.4. MPLS TLV 238 The MPLS TLV has a Type 4. The format of the MPLS TLV is TBD. 240 4. Capability Advertisement 242 A BGP speaker that wishes to exchange the IPv4-Tunnel SAFI, MUST use 243 the MP_EXT Capability Code as defined in [BGP-MP], to advertise the 244 corresponding (AFI, SAFI) pair. 246 A BGP speaker MAY participate in the distribution of IPv4-Tunnel 247 information. 249 5. Operation 251 A BGP Speaker that receives the Capability for the IPv4-Tunnel or 252 IPv6-Tunnel SAFI, MAY advertise the IPv4-Tunnel or IPv6-Tunnel 253 prefixes to that peer respectively. 255 In the UPDATE message for this SAFI sent to a peer, a BGP speaker 256 MUST only advertise the SAFI-specific attribute [BGP-SSA] TLVs that 257 are defined as valid for this SAFI. 259 If a BGP Speaker receives an SSA TLV that it does not recognize, it 260 will accept it and propagate it to other peers. 262 6. Deployment Considerations 264 In order for the Tunnels to come up between two end-points, the BGP 265 Speakers advertising the Tunnel end-points using the Ipv4 Tunnel 266 SAFI, MUST exchange at least one common encapsulation option. 268 7. Security Considerations 269 This extension to BGP does not change the underlying security issues. 271 8. Acknowledgements 273 We would like to thank Jim Guichard, Arjun Sreekantiah, Shyam Suri, 274 Chandrashekhar Appanna, John Scudder and Mark Townsley for their 275 comments and suggestions. 277 9. References 279 [IANA-AFI] http://www.iana.org/assignments/address-family-numbers 281 [IANA-SAFI] http://www.iana.org/assignments/safi-namespace 283 [BGP-4] Rekhter, Y. and T. Li (editors), "A Border Gateway Protocol 284 4 (BGP-4)", Internet Draft draft-ietf-idr-bgp4-22.txt, February 2004. 286 [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with 287 BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002. 289 [BGP-SSA] Kapoor R., Nalawade G., "BGPv4 SAFI-Specific Attribute", 290 draft-nalawade-kapoor-bgp-ssa-02.txt, work in progress. 292 [MULTI-BGP] Bates et al, "Multiprotocol Extensions for BGP-4", draft- 293 ietf-idr-rfc2858bis-02.txt, work in progress. 295 [BGP-UPDATEv2] Nalawade G.et al, "BGPv4 Update-v2 Message", draft- 296 nalawade-bgp-update-v2-01.txt, work in progress. 298 10. Authors' Addresses 300 Gargi Nalawade 301 Cisco Systems, Inc 302 170 West Tasman Drive 303 San Jose, CA 95134 304 mailto:gargi@cisco.com 306 Ruchi Kapoor 307 Cisco Systems, Inc 308 170 West Tasman Drive 309 San Jose, CA 95134 310 mailto:ruchi@cisco.com 312 Dan Tappan 313 Cisco Systems, Inc 314 170 West Tasman Drive 315 San Jose, CA 95134 316 mailto:tappan@cisco.com 318 11. Intellectual Property Statement 320 The IETF takes no position regarding the validity or scope of any 321 Intellectual Property Rights or other rights that might be claimed to 322 pertain to the implementation or use of the technology described in 323 this document or the extent to which any license under such rights 324 might or might not be available; nor does it represent that it has 325 made any independent effort to identify any such rights. Information 326 on the procedures with respect to rights in RFC documents can be 327 found in BCP 78 and BCP 79. 329 Copies of IPR disclosures made to the IETF Secretariat and any 330 assurances of licenses to be made available, or the result of an 331 attempt made to obtain a general license or permission for the use of 332 such proprietary rights by implementors or users of this 333 specification can be obtained from the IETF on-line IPR repository at 334 http://www.ietf.org/ipr. 336 The IETF invites any interested party to bring to its attention any 337 copyrights, patents or patent applications, or other proprietary 338 rights which may cover technology that may be required to practice 339 this standard. Please address the information to the IETF Executive 340 Director. 342 The IETF invites any interested party to bring to its attention any 343 copyrights, patents or patent applications, or other proprietary 344 rights that may cover technology that may be required to implement 345 this standard. Please address the information to the IETF at ietf- 346 ipr@ietf.org. 348 12. Full Copyright Statement 350 Copyright (C) The Internet Society (year). This document is subject 351 to the rights, licenses and restrictions contained in BCP 78, and 352 except as set forth therein, the authors retain all their rights." 354 "This document and the information contained herein are provided on 355 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 356 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 357 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 358 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 359 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 360 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 362 13. Expiratio 363 n Date 365 This memo is filed as , and 366 expires April, 2004.