draft-ietf-softwire-bgp-te-attribute-04.txt   rfc5543.txt 
Network Working Group Hamid Ould-Brahim (Nortel Networks)
Internet Draft Don Fedyk (Nortel Networks)
Expiration Date: June 2009 Yakov Rekhter (Juniper Networks)
Intended Status: Proposed Standard
Network Working Group H. Ould-Brahim
Request for Comments: 5543 Nortel Networks
Category: Standards Track D. Fedyk
Alcatel-Lucent
Y. Rekhter
Juniper Networks
BGP Traffic Engineering Attribute BGP Traffic Engineering Attribute
draft-ietf-softwire-bgp-te-attribute-04.txt Status of This Memo
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/ietf/1id-abstracts.txt Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html.
Copyright (c) 2008 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
This document defines a new BGP attribute, Traffic Engineering This document defines a new BGP attribute, the Traffic Engineering
attribute, that enables BGP to carry Traffic Engineering information. attribute, that enables BGP to carry Traffic Engineering information.
The scope and applicability of this attribute currently excludes its The scope and applicability of this attribute currently excludes its
use for non-VPN reachability information. use for non-VPN reachability information.
1. Specification of Requirements 1. Introduction
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Introduction
In certain cases (e.g., L1VPN [RFC5195]) it may be useful to augment In certain cases (e.g., Layer-1 VPNs (L1VPNs) [RFC5195]), it may be
VPN reachability information carried in BGP with the Traffic useful to augment the VPN reachability information carried in BGP
Engineering information. with Traffic Engineering information.
This document defines a new BGP attribute, Traffic Engineering This document defines a new BGP attribute, the Traffic Engineering
attribute, that enables BGP [RFC4271] to carry Traffic Engineering attribute, that enables BGP [RFC4271] to carry Traffic Engineering
information. information.
Section 4 of [RFC5195] describes one possible usage of this Section 4 of [RFC5195] describes one possible usage of this
attribute. attribute.
The scope and applicability of this attribute currently excludes its The scope and applicability of this attribute currently excludes its
use for non-VPN reachability information. use for non-VPN reachability information.
Procedures for modifying the Traffic Engineering attribute, when re- Procedures for modifying the Traffic Engineering attribute, when
advertising a route that carries such attribute are outside the scope re-advertising a route that carries such an attribute, are outside
of this document. the scope of this document.
2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Traffic Engineering Attribute 3. Traffic Engineering Attribute
Traffic Engineering attribute is an optional non-transitive BGP The Traffic Engineering attribute is an optional, non-transitive BGP
attribute. attribute.
The information carried in this attribute is identical to what is The information carried in this attribute is identical to what is
carried in the Interface Switching Capability Descriptor, as carried in the Interface Switching Capability Descriptor, as
specified in [RFC4203], [RFC5307]. specified in [RFC4203] and [RFC5307].
The attribute contains one or more of the following: The attribute contains one or more of the following:
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved | | Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 0 | | Max LSP Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 107 skipping to change at page 3, line 26
| Max LSP Bandwidth at priority 3 | | Max LSP Bandwidth at priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 4 | | Max LSP Bandwidth at priority 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 5 | | Max LSP Bandwidth at priority 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 6 | | Max LSP Bandwidth at priority 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 7 | | Max LSP Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Capability-specific information | | Switching Capability specific information |
| (variable) | | (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Switching Capability (Switching Cap) field contains one of the The Switching Capability (Switching Cap) field contains one of the
values specified in Section 3.1.1 of [RFC3471]. values specified in Section 3.1.1 of [RFC3471].
The Encoding field contains one of the values specified in Section The Encoding field contains one of the values specified in Section
3.1.1 of [RFC3471]. 3.1.1 of [RFC3471].
The Reserved field SHOULD be set to 0 on transmit and MUST be ignored The Reserved field SHOULD be set to 0 on transmit and MUST be ignored
on receive. on receive.
Maximum LSP Bandwidth is encoded as a list of eight 4 octet fields in Maximum LSP (Label Switched Path) Bandwidth is encoded as a list of
the IEEE floating point format [IEEE], with priority 0 first and eight 4-octet fields in the IEEE floating point format [IEEE], with
priority 7 last. The units are bytes (not bits!) per second. priority 0 first and priority 7 last. The units are bytes (not
bits!) per second.
The content of the Switching Capability specific information field The content of the Switching Capability specific information field
depends on the value of the Switching Capability field. depends on the value of the Switching Capability field.
When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4, When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4,
the Switching Capability specific information field includes Minimum the Switching Capability specific information field includes Minimum
LSP Bandwidth and Interface MTU. LSP Bandwidth and Interface MTU.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum LSP Bandwidth | | Minimum LSP Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU | | Interface MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Minimum LSP Bandwidth is encoded in a 4 octet field in the IEEE Minimum LSP Bandwidth is encoded in a 4-octet field in the IEEE
floating point format. The units are bytes (not bits!) per second. floating point format. The units are bytes (not bits!) per second.
The Interface MTU is encoded as a 2 octet integer. Interface MTU is encoded as a 2-octet integer.
When the Switching Capability field is L2SC, there is no Switching When the Switching Capability field is Layer-2 Switch Capable (L2SC),
Capability specific information field present. there is no Switching Capability specific information field present.
When the Switching Capability field is TDM, the Switching Capability When the Switching Capability field is Time-Division-Multiplex (TDM)
specific information field includes Minimum LSP Bandwidth and an capable, the Switching Capability specific information field includes
indication of whether the interface supports Standard or Arbitrary Minimum LSP Bandwidth and an indication of whether the interface
SONET/SDH. supports Standard or Arbitrary SONET/SDH (Synchronous Optical
Network / Synchronous Digital Hierarchy).
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum LSP Bandwidth | | Minimum LSP Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Indication | | Indication |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The Minimum LSP Bandwidth is encoded in a 4 octet field in the IEEE Minimum LSP Bandwidth is encoded in a 4-octet field in the IEEE
floating point format. The units are bytes (not bits!) per second. floating point format. The units are bytes (not bits!) per second.
The indication of whether the interface supports Standard or The indication of whether the interface supports Standard or
Arbitrary SONET/SDH is encoded as 1 octet. The value of this octet Arbitrary SONET/SDH is encoded as 1 octet. The value of this octet
is 0 if the interface supports Standard SONET/SDH, and 1 if the is 0 if the interface supports Standard SONET/SDH, and 1 if the
interface supports Arbitrary SONET/SDH. interface supports Arbitrary SONET/SDH.
When the Switching Capability field is LSC, there is no Switching When the Switching Capability field is Lambda Switch Capable (LSC),
Capability specific information field present. there is no Switching Capability specific information field present.
4. Implication on aggregation 4. Implication on Aggregation
Routes that carry the Traffic Engineering Attribute have additional Routes that carry the Traffic Engineering attribute have additional
semantics that could affect traffic forwarding behavior. Therefore, semantics that could affect traffic-forwarding behavior. Therefore,
such routes SHALL NOT be aggregated unless they share identical such routes SHALL NOT be aggregated unless they share identical
Traffic Engineering Attributes. Traffic Engineering attributes.
Constructing the Traffic Engineering Attribute when aggregating Constructing the Traffic Engineering attribute when aggregating
routes with identical Traffic Engineering attributes follows the routes with identical Traffic Engineering attributes follows the
procedure of [RFC4201]. procedure of [RFC4201].
5. Implication on scalability 5. Implication on Scalability
The use of the Traffic Engineering Attribute does not increase the The use of the Traffic Engineering attribute does not increase the
number of routes, but may increase the number of BGP Update messages number of routes, but may increase the number of BGP Update messages
required to distribute the routes depending on whether these routes required to distribute the routes, depending on whether or not these
share the same BGP Traffic Engineering attribute or not (see below). routes share the same BGP Traffic Engineering attribute (see below).
When the routes differ in other than the Traffic Engineering When the routes differ other than in the Traffic Engineering
Attribute (e.g., differ in the set of Route Targets, and/or attribute (e.g., differ in the set of Route Targets and/or NEXT_HOP),
NEXT_HOP), use of Traffic Engineering Attribute has no impact on the use of the Traffic Engineering attribute has no impact on the number
number of BGP Update messages required to carry the routes. There is of BGP Update messages required to carry the routes. There is also
also no impact when routes share all other attribute information and no impact when routes share all other attribute information and have
have an aggregated or identical Traffic Engineering Attribute. When an aggregated or identical Traffic Engineering attribute. When
routes share all other attribute information and have different routes share all other attribute information and have different
Traffic Engineering Attributes, routes must be distributed in per- Traffic Engineering attributes, routes must be distributed in
route BGP Update messages rather than a single message. per-route BGP Update messages, rather than in a single message.
6. IANA Considerations 6. IANA Considerations
This document defines a new BGP attribute. This attribute is optional This document defines a new BGP attribute, Traffic Engineering. This
and non-transitive. attribute is optional and non-transitive.
7. Security Considerations 7. Security Considerations
This extension to BGP does not change the underlying security issues This extension to BGP does not change the underlying security issues
currently inherent in BGP. BGP security considerations are discussed currently inherent in BGP. BGP security considerations are discussed
in RFC 4271 in RFC 4271.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank John Scudder and Jeffrey Haas for The authors would like to thank John Scudder and Jeffrey Haas for
their review and comments. their review and comments.
9. Normative References 9. References
9.1. Normative References
[IEEE] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic",
Standard 754-1985, 1985 (ISBN 1-5593-7653-8).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
MPLS Traffic Engineering (TE)", RFC 4201, October 2005<P> Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC4271] Rekhter, Y., T. Li, Hares, S., "A Border Gateway Protocol 4
(BGP-4)", RFC4271, January 2006.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in
(GMPLS) Signaling Functional Description", RFC 3471, January 2003. MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[IEEE] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border
Standard 754-1985, 1985 (ISBN 1-5593-7653-8). Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
10. Non-Normative References 9.2. Informative References
[RFC4203] Kompella, K., Rekhter, Y., "OSPF Extensions in Support of [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in
Generalized Multi-Protocol Label Switching (GMPLS)", RFC4203, October Support of Generalized Multi-Protocol Label Switching
2005 (GMPLS)", RFC 4203, October 2005.
[RFC5307] Kompella, K., Rekhter, Y., "Intermediate System to [RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based
Intermediate System (IS-IS) Extensions in Support of Generalized Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.
Multi-Protocol Label Switching (GMPLS)", RFC5307, October 2005
[RFC5195] Ould-Brahim, H., Fedyk, D., Rekhter, Y., "BGP-Based Auto- [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, October 2008.
11. Author Information Authors' Addresses
Hamid Ould-Brahim Hamid Ould-Brahim
Nortel Networks Nortel Networks
Email: hbrahim@nortel.com EMail: hbrahim@nortel.com
Don Fedyk Don Fedyk
Nortel Networks Alcatel-Lucent
Email: dwfedyk@nortel.com EMail: donald.fedyk@alcatel-lucent.com
Phone: 978-467-5645
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
email: yakov@juniper.com EMail: yakov@juniper.net
 End of changes. 45 change blocks. 
104 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/