idnits 2.17.1 draft-ietf-softwire-bgp-te-attribute-00.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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 196. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 169. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 176. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 182. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE' -- Obsolete informational reference (is this intentional?): RFC 4205 (Obsoleted by RFC 5307) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Hamid Ould-Brahim (Nortel Networks) 3 Internet Draft Don Fedyk (Nortel Networks) 4 Expiration Date: July 2008 Yakov Rekhter (Juniper Networks) 5 Intended Status: Proposed Standard 7 Traffic Engineering Attribute 9 draft-ietf-softwire-bgp-te-attribute-00.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 or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 This document defines a new BGP attribute, Traffic Engineering 37 attribute, than enables BGP to carry Traffic Engineering information. 39 1. Specification of Requirements 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in RFC 2119 [RFC2119]. 45 2. Introduction 47 In certain cases (e.g., L1VPN [L1VPN]) it may be useful to augment 48 reachability information carried in BGP with the Traffic Engineering 49 information. 51 This document defines a new BGP attribute, Traffic Engineering 52 attribute, than enables BGP [BGP-4] to carry Traffic Engineering 53 information. 55 3. Traffic Engineering Attribute 57 Traffic Engineering attribute is an optional non-transitive BGP 58 attribute. 60 The information carried in this attribute is identical to what is 61 carried in the Interface Switching Capability Descriptor, as 62 specified in [RFC4203], [RFC4205]. 64 The attribute contains one or more of the following: 66 0 1 2 3 67 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 68 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 69 | Switching Cap | Encoding | Reserved | 70 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 71 | Max LSP Bandwidth at priority 0 | 72 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 73 | Max LSP Bandwidth at priority 1 | 74 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 75 | Max LSP Bandwidth at priority 2 | 76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 77 | Max LSP Bandwidth at priority 3 | 78 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 79 | Max LSP Bandwidth at priority 4 | 80 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 81 | Max LSP Bandwidth at priority 5 | 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 | Max LSP Bandwidth at priority 6 | 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 85 | Max LSP Bandwidth at priority 7 | 86 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 87 | Switching Capability-specific information | 88 | (variable) | 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 The Switching Capability (Switching Cap) field contains one of the 92 values specified in Section 3.1.1 of [GMPLS-SIG]. 94 The Encoding field contains one of the values specified in Section 95 3.1.1 of [GMPLS-SIG]. 97 The Reserved field SHOULD be set to 0 on transmit and MUST be ignored 98 on receive. 100 Maximum LSP Bandwidth is encoded as a list of eight 4 octet fields in 101 the IEEE floating point format [IEEE], with priority 0 first and 102 priority 7 last. The units are bytes (not bits!) per second. 104 The content of the Switching Capability specific information field 105 depends on the value of the Switching Capability field. 107 When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4, 108 the Switching Capability specific information field includes Minimum 109 LSP Bandwidth and Interface MTU. 111 0 1 2 3 112 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 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Minimum LSP Bandwidth | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Interface MTU | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 The Minimum LSP Bandwidth is encoded in a 4 octet field in the IEEE 120 floating point format. The units are bytes (not bits!) per second. 121 The Interface MTU is encoded as a 2 octet integer. 123 When the Switching Capability field is L2SC, there is no Switching 124 Capability specific information field present. 126 When the Switching Capability field is TDM, the Switching Capability 127 specific information field includes Minimum LSP Bandwidth and an 128 indication of whether the interface supports Standard or Arbitrary 129 SONET/SDH. 131 0 1 2 3 132 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Minimum LSP Bandwidth | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Indication | 138 +-+-+-+-+-+-+-+-+ 140 The Minimum LSP Bandwidth is encoded in a 4 octet field in the IEEE 141 floating point format. The units are bytes (not bits!) per second. 142 The indication of whether the interface supports Standard or 143 Arbitrary SONET/SDH is encoded as 1 octet. The value of this octet 144 is 0 if the interface supports Standard SONET/SDH, and 1 if the 145 interface supports Arbitrary SONET/SDH. 147 When the Switching Capability field is LSC, there is no Switching 148 Capability specific information field present. 150 4. IANA Considerations 152 This document defines a new BGP attribute. This attribute is optional 153 and non-transitive. 155 5. Security Considerations 157 This extension to BGP does not change the underlying security issues 158 inherent in the existing BGP. 160 6. Intellectual Property Statement 162 The IETF takes no position regarding the validity or scope of any 163 Intellectual Property Rights or other rights that might be claimed to 164 pertain to the implementation or use of the technology described in 165 this document or the extent to which any license under such rights 166 might or might not be available; nor does it represent that it has 167 made any independent effort to identify any such rights. Information 168 on the procedures with respect to rights in RFC documents can be 169 found in BCP 78 and BCP 79. 171 Copies of IPR disclosures made to the IETF Secretariat and any 172 assurances of licenses to be made available, or the result of an 173 attempt made to obtain a general license or permission for the use of 174 such proprietary rights by implementers or users of this 175 specification can be obtained from the IETF on-line IPR repository at 176 http://www.ietf.org/ipr. 178 The IETF invites any interested party to bring to its attention any 179 copyrights, patents or patent applications, or other proprietary 180 rights that may cover technology that may be required to implement 181 this standard. Please address the information to the IETF at ietf- 182 ipr@ietf.org. 184 7. Copyright (C) The IETF Trust (2008). 186 This document is subject to the rights, licenses and restrictions 187 contained in BCP 78, and except as set forth therein, the authors 188 retain all their rights. 190 This document and the information contained herein are provided on an 191 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 192 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 193 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 194 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 195 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 196 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 198 8. Acknowledgements 200 The authors would like to thank John Scudder for his review and 201 comments. 203 9. Normative References 205 [BGP-4] Rekhter, Y., T. Li, Hares, S., "A Border Gateway Protocol 4 206 (BGP-4)", RFC4271, January 2006. 208 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 209 Requirement Levels", BCP 14, RFC 2119, March 1997. 211 [GMPLS-SIG] Berger, L., "Generalized Multi-Protocol Label Switching 212 (GMPLS) Signaling Functional Description", RFC 3471, January 2003. 214 [IEEE] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", 215 Standard 754-1985, 1985 (ISBN 1-5593-7653-8). 217 10. Non-Normative References 219 [RFC4203] Kompella, K., Rekhter, Y., "OSPF Extensions in Support of 220 Generalized Multi-Protocol Label Switching (GMPLS)", RFC4203, October 221 2005 223 [RFC4205] Kompella, K., Rekhter, Y., "Intermediate System to 224 Intermediate System (IS-IS) Extensions in Support of Generalized 225 Multi-Protocol Label Switching (GMPLS)", RFC4205, October 2005 227 [L1VPN] Fedyk, D., Ould-Brahim, H., Rekhter, Y., "BGP-based Auto- 228 Discovery for L1VPNs", draft-ietf-l1vpn-bgp-auto-discovery, work in 229 progress 231 11. Author Information 233 Hamid Ould-Brahim 234 Nortel Networks 235 Email: hbrahim@nortel.com 237 Don Fedyk 238 Nortel Networks 239 Email: dwfedyk@nortel.com 241 Yakov Rekhter 242 Juniper Networks, Inc. 243 email: yakov@juniper.com