idnits 2.17.1 draft-ietf-softwire-bgp-te-attribute-04.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 302 lines 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 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' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Hamid Ould-Brahim (Nortel Networks) 2 Internet Draft Don Fedyk (Nortel Networks) 3 Expiration Date: June 2009 Yakov Rekhter (Juniper Networks) 4 Intended Status: Proposed Standard 6 BGP Traffic Engineering Attribute 8 draft-ietf-softwire-bgp-te-attribute-04.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 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 Copyright (c) 2008 IETF Trust and the persons identified as the 32 document authors. All rights reserved. 34 This document is subject to BCP 78 and the IETF Trust's Legal 35 Provisions Relating to IETF Documents 36 (http://trustee.ietf.org/license-info) in effect on the date of 37 publication of this document. Please review these documents 38 carefully, as they describe your rights and restrictions with respect 39 to this document. 41 Abstract 43 This document defines a new BGP attribute, Traffic Engineering 44 attribute, that enables BGP to carry Traffic Engineering information. 46 The scope and applicability of this attribute currently excludes its 47 use for non-VPN reachability information. 49 1. Specification of Requirements 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [RFC2119]. 55 2. Introduction 57 In certain cases (e.g., L1VPN [RFC5195]) it may be useful to augment 58 VPN reachability information carried in BGP with the Traffic 59 Engineering information. 61 This document defines a new BGP attribute, Traffic Engineering 62 attribute, that enables BGP [RFC4271] to carry Traffic Engineering 63 information. 65 Section 4 of [RFC5195] describes one possible usage of this 66 attribute. 68 The scope and applicability of this attribute currently excludes its 69 use for non-VPN reachability information. 71 Procedures for modifying the Traffic Engineering attribute, when re- 72 advertising a route that carries such attribute are outside the scope 73 of this document. 75 3. Traffic Engineering Attribute 77 Traffic Engineering attribute is an optional non-transitive BGP 78 attribute. 80 The information carried in this attribute is identical to what is 81 carried in the Interface Switching Capability Descriptor, as 82 specified in [RFC4203], [RFC5307]. 84 The attribute contains one or more of the following: 86 0 1 2 3 87 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 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | Switching Cap | Encoding | Reserved | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 | Max LSP Bandwidth at priority 0 | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 | Max LSP Bandwidth at priority 1 | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | Max LSP Bandwidth at priority 2 | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | Max LSP Bandwidth at priority 3 | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | Max LSP Bandwidth at priority 4 | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | Max LSP Bandwidth at priority 5 | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | Max LSP Bandwidth at priority 6 | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Max LSP Bandwidth at priority 7 | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Switching Capability-specific information | 108 | (variable) | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 The Switching Capability (Switching Cap) field contains one of the 112 values specified in Section 3.1.1 of [RFC3471]. 114 The Encoding field contains one of the values specified in Section 115 3.1.1 of [RFC3471]. 117 The Reserved field SHOULD be set to 0 on transmit and MUST be ignored 118 on receive. 120 Maximum LSP Bandwidth is encoded as a list of eight 4 octet fields in 121 the IEEE floating point format [IEEE], with priority 0 first and 122 priority 7 last. The units are bytes (not bits!) per second. 124 The content of the Switching Capability specific information field 125 depends on the value of the Switching Capability field. 127 When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4, 128 the Switching Capability specific information field includes Minimum 129 LSP Bandwidth and Interface MTU. 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 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Minimum LSP Bandwidth | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Interface MTU | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 The Minimum LSP Bandwidth is encoded in a 4 octet field in the IEEE 140 floating point format. The units are bytes (not bits!) per second. 141 The Interface MTU is encoded as a 2 octet integer. 143 When the Switching Capability field is L2SC, there is no Switching 144 Capability specific information field present. 146 When the Switching Capability field is TDM, the Switching Capability 147 specific information field includes Minimum LSP Bandwidth and an 148 indication of whether the interface supports Standard or Arbitrary 149 SONET/SDH. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Minimum LSP Bandwidth | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Indication | 157 +-+-+-+-+-+-+-+-+ 159 The Minimum LSP Bandwidth is encoded in a 4 octet field in the IEEE 160 floating point format. The units are bytes (not bits!) per second. 161 The indication of whether the interface supports Standard or 162 Arbitrary SONET/SDH is encoded as 1 octet. The value of this octet 163 is 0 if the interface supports Standard SONET/SDH, and 1 if the 164 interface supports Arbitrary SONET/SDH. 166 When the Switching Capability field is LSC, there is no Switching 167 Capability specific information field present. 169 4. Implication on aggregation 171 Routes that carry the Traffic Engineering Attribute have additional 172 semantics that could affect traffic forwarding behavior. Therefore, 173 such routes SHALL NOT be aggregated unless they share identical 174 Traffic Engineering Attributes. 176 Constructing the Traffic Engineering Attribute when aggregating 177 routes with identical Traffic Engineering attributes follows the 178 procedure of [RFC4201]. 180 5. Implication on scalability 182 The use of the Traffic Engineering Attribute does not increase the 183 number of routes, but may increase the number of BGP Update messages 184 required to distribute the routes depending on whether these routes 185 share the same BGP Traffic Engineering attribute or not (see below). 187 When the routes differ in other than the Traffic Engineering 188 Attribute (e.g., differ in the set of Route Targets, and/or 189 NEXT_HOP), use of Traffic Engineering Attribute has no impact on the 190 number of BGP Update messages required to carry the routes. There is 191 also no impact when routes share all other attribute information and 192 have an aggregated or identical Traffic Engineering Attribute. When 193 routes share all other attribute information and have different 194 Traffic Engineering Attributes, routes must be distributed in per- 195 route BGP Update messages rather than a single message. 197 6. IANA Considerations 199 This document defines a new BGP attribute. This attribute is optional 200 and non-transitive. 202 7. Security Considerations 204 This extension to BGP does not change the underlying security issues 205 currently inherent in BGP. BGP security considerations are discussed 206 in RFC 4271 208 8. Acknowledgements 210 The authors would like to thank John Scudder and Jeffrey Haas for 211 their review and comments. 213 9. Normative References 215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, March 1997. 218 [RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 219 MPLS Traffic Engineering (TE)", RFC 4201, October 2005

221 [RFC4271] Rekhter, Y., T. Li, Hares, S., "A Border Gateway Protocol 4 222 (BGP-4)", RFC4271, January 2006. 224 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 225 (GMPLS) Signaling Functional Description", RFC 3471, January 2003. 227 [IEEE] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", 228 Standard 754-1985, 1985 (ISBN 1-5593-7653-8). 230 10. Non-Normative References 232 [RFC4203] Kompella, K., Rekhter, Y., "OSPF Extensions in Support of 233 Generalized Multi-Protocol Label Switching (GMPLS)", RFC4203, October 234 2005 236 [RFC5307] Kompella, K., Rekhter, Y., "Intermediate System to 237 Intermediate System (IS-IS) Extensions in Support of Generalized 238 Multi-Protocol Label Switching (GMPLS)", RFC5307, October 2005 240 [RFC5195] Ould-Brahim, H., Fedyk, D., Rekhter, Y., "BGP-Based Auto- 241 Discovery for Layer-1 VPNs", RFC5195, June 2008 243 11. Author Information 245 Hamid Ould-Brahim 246 Nortel Networks 247 Email: hbrahim@nortel.com 249 Don Fedyk 250 Nortel Networks 251 Email: dwfedyk@nortel.com 253 Yakov Rekhter 254 Juniper Networks, Inc. 255 email: yakov@juniper.com