draft-ietf-idr-large-community-01.txt   draft-ietf-idr-large-community-02.txt 
IDR J. Heitz IDR J. Heitz
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track K. Patel Intended status: Standards Track K. Patel
Expires: April 4, 2017 Arrcus Expires: April 11, 2017 Arrcus
J. Snijders J. Snijders
NTT NTT
I. Bagdonas I. Bagdonas
Equinix Equinix
A. Simpson A. Simpson
Nokia Nokia
October 1, 2016 October 8, 2016
Large BGP Communities Large BGP Communities
draft-ietf-idr-large-community-01 draft-ietf-idr-large-community-02
Abstract Abstract
This document describes the Large BGP Community attribute, an This document describes the Large BGP Community attribute, an
extension to BGP (RFC 4271). This attribute provides a mechanism to extension to BGP-4. This attribute provides a mechanism to signal
signal opaque information within separate namespaces to aid in opaque information within separate namespaces to aid in routing
routing management. The attribute is suitable for use in 4-byte ASNs management. The attribute is suitable for use in 4-octet ASNs.
(RFC 6793).
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 47 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 4, 2017. This Internet-Draft will expire on April 11, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 41 skipping to change at page 3, line 41
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Administrator | | Global Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Data Part 1 | | Local Data Part 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Data Part 2 | | Local Data Part 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Global Administrator: A four-octet namespace identifier. This Global Administrator: A four-octet namespace identifier. This
SHOULD be an Autonomous System Number assigned by IANA. SHOULD be an Autonomous System Number.
Local Data Part 1: A four-octet operator-defined value. Local Data Part 1: A four-octet operator-defined value.
Local Data Part 2: A four-octet operator-defined value. Local Data Part 2: A four-octet operator-defined value.
The Global Administrator field is intended to allow different The Global Administrator field is intended to allow different
Autonomous Systems to define Large Communities without collision. Autonomous Systems to define Large Communities without collision.
Implementations MUST allow the operator to specify any value for the Implementations MUST allow the operator to specify any value for the
Global Administrator field. Global Administrator field.
There is no significance to the order in which Large Communities are There is no significance to the order in which Large Communities are
encoded in a path attributes field and a receiving speaker MAY encoded in a path attributes field and a receiving speaker MAY
retransmit them in an order different from which it received them. retransmit them in an order different from which it received them.
Duplicate Large Communities SHOULD NOT be transmitted. A receiving Duplicate Large Communities SHOULD NOT be transmitted. A receiving
speaker SHOULD silently remove duplicate Large Communities from a BGP speaker SHOULD silently remove duplicate Large Communities from a BGP
UPDATE message. UPDATE message.
There are no routing semantics implied by the Global Administrator
field.
3. Aggregation 3. Aggregation
If a range of routes is aggregated and the resulting aggregates If a range of routes is aggregated and the resulting aggregates
attribute section does not carry the ATOMIC_AGGREGATE attribute, then attribute section does not carry the ATOMIC_AGGREGATE attribute, then
the resulting aggregate should have a Large Communities path the resulting aggregate should have a Large Communities path
attribute which contains all of the large communities from all of the attribute which contains all of the large communities from all of the
aggregated routes. aggregated routes.
4. Textual Representation 4. Textual Representation
BGP Communities [RFC1997] are usually represented in routing policy BGP Communities [RFC1998] are usually represented in routing policy
languages as two individual two-octet unsigned integers separated by languages as two individual two-octet unsigned integers separated by
a colon; for example, 64496:12345. a colon; for example, 64496:12345.
BGP Large Communities implementations MUST represent Large BGP Large Communities implementations MUST represent Large
Communities in a manner similar to their representation of BGP Communities in a manner similar to their representation of BGP
Communities [RFC1997]. Large Communities MUST be represented as Communities [RFC1998]. Large Communities MUST be represented as
three separate four-octet unsigned integers in decimal format with no three separate four-octet unsigned integers in decimal format with no
leading zeros. These integers MUST NOT be omitted, even when zero. leading zeros. These integers MUST NOT be omitted, even when zero.
For example, 64496:4294967295:2 or 64496:0:0. For example, 64496:4294967295:2 or 64496:0:0.
Vendors MAY provide other textual representations. For example, a Vendors MAY provide other textual representations. For example, a
vendor's routing policy language may use a separator other than a vendor's routing policy language may use a separator other than a
colon or may require keywords or characters prepending or postpending colon or may require keywords or characters prepending or postpending
the Large Communities attribute. Such differences are permitted. the Large Communities attribute. Such differences are permitted.
However, each implementation MUST make a representation available However, each implementation MUST make a representation available
that depicts the integers in decimal and in the following order: that depicts the integers in decimal and in the following order:
skipping to change at page 5, line 25 skipping to change at page 5, line 25
o A BGP UPDATE message with a malformed Large Communities attribute o A BGP UPDATE message with a malformed Large Communities attribute
SHALL be handled using the approach of "treat-as-withdraw" as SHALL be handled using the approach of "treat-as-withdraw" as
described in section 2 [RFC7606]. described in section 2 [RFC7606].
The BGP Large Communities Global Administrator field may contain any The BGP Large Communities Global Administrator field may contain any
value, and a Large Communities attribute MUST NOT be considered value, and a Large Communities attribute MUST NOT be considered
malformed if the Global Administrator field contains an unallocated, malformed if the Global Administrator field contains an unallocated,
unassigned or reserved ASN or is set to one of the reserved Large BGP unassigned or reserved ASN or is set to one of the reserved Large BGP
Community values defined in Section 5. Community values defined in Section 5.
A receiving speaker MUST NOT consider duplicate Large Communities
attributes in a BGP UPDATE message to be malformed.
7. Security Considerations 7. Security Considerations
This extension to BGP has similar security implications as BGP This extension to BGP has similar security implications as BGP
Communities [RFC1997] and BGP Extended Communities [RFC4360]. Communities [RFC1997].
This document does not change any underlying security issues This document does not change any underlying security issues
associated with any other BGP Communities mechanism. Specifically, associated with any other BGP Communities mechanism. Specifically,
an AS relying on the Large BGP Community attribute carried in BGP an AS relying on the Large BGP Community attribute carried in BGP
must have trust in every other AS in the path, as any intermediate must have trust in every other AS in the path, as any intermediate
Autonomous System in the path may have added, deleted or altered the Autonomous System in the path may have added, deleted or altered the
Large BGP Community attribute. Specifying the mechanism to provide Large BGP Community attribute. Specifying the mechanism to provide
such trust is beyond the scope of this document. such trust is beyond the scope of this document.
Network administrators should note the recommendations in Section 11 Network administrators should note the recommendations in Section 11
skipping to change at page 6, line 21 skipping to change at page 6, line 18
BGP Community: BGP Community:
o Cisco IOS XR o Cisco IOS XR
o ExaBGP o ExaBGP
o GoBGP o GoBGP
o BIRD o BIRD
o OpenBGPD
The latest implementation news is tracked at The latest implementation news is tracked at
http://largebgpcommunities.net/ [1]. http://largebgpcommunities.net/ [1].
9. IANA Considerations 9. IANA Considerations
IANA has assigned value 30 (LARGE_COMMUNITY Attribute) in the "BGP IANA has made an Early Allocation of the value 30 (LARGE_COMMUNITY)
Path Attributes" sub-registry under the "Border Gateway Protocol in the "BGP Path Attributes" registry under the "Border Gateway
(BGP) Parameters" registry. Protocol (BGP) Parameters" group and is now asked to make that
Permanent.
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Ruediger Volk, Russ White, Acee The authors would like to thank Ruediger Volk, Russ White, Acee
Lindem, Shyam Sethuram, Jared Mauch, Joel M. Halpern, Nick Hilliard, Lindem, Shyam Sethuram, Jared Mauch, Joel M. Halpern, Nick Hilliard,
Jeffrey Haas, John Heasley, Gunter van de Velde, Marco Marzetti, Jeffrey Haas, John Heasley, Gunter van de Velde, Marco Marzetti,
Eduardo Ascenco Reis, Mark Schouten, Paul Hoogsteder, Martijn Eduardo Ascenco Reis, Mark Schouten, Paul Hoogsteder, Martijn
Schmidt, Greg Hankins, Acee Lindem, Bertrand Duvivier, Barry Schmidt, Greg Hankins, Acee Lindem, Bertrand Duvivier, Barry
O'Donovan, Grzegorz Janoszka, Linda Dunbar, Marco Davids, Gaurab Raj O'Donovan, Grzegorz Janoszka, Linda Dunbar, Marco Davids, Gaurab Raj
Upadhaya, Jeff Tantsura, Teun Vink, Adam Davenport, Theodore Baschak, Upadhaya, Jeff Tantsura, Teun Vink, Adam Davenport, Theodore Baschak,
skipping to change at page 7, line 30 skipping to change at page 7, line 30
DOI 10.17487/RFC6793, December 2012, DOI 10.17487/RFC6793, December 2012,
<http://www.rfc-editor.org/info/rfc6793>. <http://www.rfc-editor.org/info/rfc6793>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages", Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<http://www.rfc-editor.org/info/rfc7606>. <http://www.rfc-editor.org/info/rfc7606>.
11.2. Informative References 11.2. Informative References
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [RFC1998] Chen, E. and T. Bates, "An Application of the BGP
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, Community Attribute in Multi-home Routing", RFC 1998,
February 2006, <http://www.rfc-editor.org/info/rfc4360>. DOI 10.17487/RFC1998, August 1996,
<http://www.rfc-editor.org/info/rfc1998>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
February 2015, <http://www.rfc-editor.org/info/rfc7454>. February 2015, <http://www.rfc-editor.org/info/rfc7454>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<http://www.rfc-editor.org/info/rfc7942>. <http://www.rfc-editor.org/info/rfc7942>.
 End of changes. 14 change blocks. 
24 lines changed or deleted 21 lines changed or added

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