draft-ietf-idr-large-community-00.txt   draft-ietf-idr-large-community-01.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: March 27, 2017 Arrcus Expires: April 4, 2017 Arrcus
J. Snijders J. Snijders
NTT NTT
I. Bagdonas I. Bagdonas
Equinix Equinix
A. Simpson A. Simpson
Nokia Nokia
September 23, 2016 October 1, 2016
Large BGP Communities Large BGP Communities
draft-ietf-idr-large-community-00 draft-ietf-idr-large-community-01
Abstract Abstract
The BGP Communities Attribute [RFC1997] is heavily used by operators, This document describes the Large BGP Community attribute, an
but is inadequate to represent large enough values, particularly extension to BGP (RFC 4271). This attribute provides a mechanism to
Four-octet Autonomous System numbers [RFC6793] plus additional signal opaque information within separate namespaces to aid in
values. This document describes an extension to BGP [RFC4271] to routing management. The attribute is suitable for use in 4-byte ASNs
address this need with a new extended form of the BGP community (RFC 6793).
Attribute.
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 48 skipping to change at page 1, line 47
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 March 27, 2017. This Internet-Draft will expire on April 4, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Large BGP Community Attribute . . . . . . . . . . . . . . . . 3 2. Large BGP Communities Attribute . . . . . . . . . . . . . . . 3
3. Textual Representation . . . . . . . . . . . . . . . . . . . 4 3. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 4. Textual Representation . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. Reserved Large BGP Community values . . . . . . . . . . . . . 4
6. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 5 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . 7
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
BGP implementations typically support a routing policy language (RPL) BGP implementations typically support a routing policy language to
to control the distribution of routing information. Network control the distribution of routing information. Network operators
operators add BGP communities to routes via the RPL to identify attach BGP communities to routes to identify intrinsic properties of
intrinsic differentia of a route such as its origin country or these routes. These properties may include information such as the
specify a RPL action to be taken, or one that has been taken, on an route origin location, or specification of a routing policy action to
individual route or group of routes. Because BGP communities are be taken, or one that has been taken, and may apply to an individual
optional transitive BGP attributes, these differentia and actions route or to a group of routes. Because BGP communities are optional
identified by the communities may be acted upon or otherwise utilized transitive BGP attributes, BGP communities may be acted upon or
by the RPL in any Autonomous System (AS) in the Internet, often are otherwise used by routing policies in other Autonomous Systems (ASes)
and often the goal of adding a community is to signal an AS one or on the Internet.
more AS-hops away.
BGP Communities Attributes are 4-octet values split into two 2-octet [RFC1997] BGP Communities Attributes are four-octet values split into
values where the most significant word is an Autonomous System number two individual two-octet words. The most significant word is usually
(ASN) and the least significant word is a value whose meaning is interpreted as an Autonomous System Number (ASN) and the least
defined by operators of that Autonomous System. This operator- significant word is a locally defined value whose meaning is assigned
defined value is the aforementioned differentia or RPL action. by the operator of the Autonomous System in the most significant
word.
Since the adoption of Four-octet ASNs [RFC6793], the BGP Communities Since the adoption of four-octet ASNs [RFC6793], the BGP Communities
Attribute can no longer accommodate this encoding because it is only Attribute can no longer accommodate this encoding, as the
large enough to hold the ASN. Some operators have also expressed a specification in [RFC1997] contains only four octets. This does not
need for more than 2-octets of operator-defined values. This has led allow operators to specify any locally significant values.
operators to create obtuse mappings to fit within 2-octets, the use
of which are tedious and error prone and still can not accommodate
all use-cases.
To address this, a Large Community BGP attribute is defined to encode To address these shortcomings, this document defines a Large
one or more 12-octet values each consisting of a Four-octet Community BGP Attribute encoded as one or more 12-octet values, each
Autonomous System Number and two 4 octet operator-defined values for consisting of a four-octet ASN and two four-octet operator-defined
differentia or actions defined by that Autonomous System. values, each of which can be used to denote properties or actions
significant to that ASN.
2. Large BGP Community Attribute 2. Large BGP Communities Attribute
This document creates the Large Communities BGP path attribute as an This document creates the Large Communities BGP path attribute as an
optional transitive attribute of variable length. All routes with optional transitive attribute of variable length. All routes with
the Large Community attribute belong to the communities in the the Large Communities attribute belong to the community specified in
attribute. the attribute.
The Large COMMUNITIES attribute has Type Code TBD - RFC EDITOR fill-
in IANA assigned value.
The attribute consists of one or more 12-octet values. Each 12-octet The attribute consists of one or more 12-octet values. Each 12-octet
Large Community value represents three 4-octet values, as follows: Large Communities value represents three 4-octet values, as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Autonomous System Number | | Global Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Data Part 1 | | Local Data Part 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Data Part 2 | | Local Data Part 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Autonomous System Number: The Four-octet ASN of the operator with Global Administrator: A four-octet namespace identifier. This
whom definition of the final two 4-octet values lies. SHOULD be an Autonomous System Number assigned by IANA.
Local Data part 1: 4-octet operator-defined value. Local Data Part 1: A four-octet operator-defined value.
Local Data part 2: 4-octet operator-defined value. Local Data Part 2: A four-octet operator-defined value.
3. Textual Representation The Global Administrator field is intended to allow different
Autonomous Systems to define Large Communities without collision.
Implementations MUST allow the operator to specify any value for the
Global Administrator field.
The textual representation of BGP Communities [RFC1997] in RPLs and There is no significance to the order in which Large Communities are
the networking community is known well as two 2-octet unsigned encoded in a path attributes field and a receiving speaker MAY
integers and is often represented as such, separated a colon. For retransmit them in an order different from which it received them.
example, 65000:12345 (ASN:differentia).
Large Communities MUST be represented similarly, as three 4-octet Duplicate Large Communities SHOULD NOT be transmitted. A receiving
unsigned integers with no leading zeros. An integer MUST NOT be speaker SHOULD silently remove duplicate Large Communities from a BGP
omitted, even when zero. Implementations MUST represent Large UPDATE message.
Communities in RPL in a manner consistent with their representation
of BGP Communities [RFC1997]. For example, 65000:1:2 (ASN:Local Data
Part 1:Local Data Part 2) or 65000:0:0.
The following Large BGP Communities textual specification uses the There are no routing semantics implied by the Global Administrator
Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234]. field.
positive-digit = "1" / "2" / "3" / 3. Aggregation
"4" / "5" / "6" /
"7" / "8" / "9"
digit = "0" / positive-digit If a range of routes is aggregated and the resulting aggregates
attribute section does not carry the ATOMIC_AGGREGATE attribute, then
the resulting aggregate should have a Large Communities path
attribute which contains all of the large communities from all of the
aggregated routes.
non-zero-int = positive-digit *9digit 4. Textual Representation
part = "0" / non-zero-int ; max value is 4294967295 BGP Communities [RFC1997] are usually represented in routing policy
languages as two individual two-octet unsigned integers separated by
a colon; for example, 64496:12345.
large-community = part ":" part ":" part BGP Large Communities implementations MUST represent Large
Communities in a manner similar to their representation of BGP
Communities [RFC1997]. Large Communities MUST be represented as
three separate four-octet unsigned integers in decimal format with no
leading zeros. These integers MUST NOT be omitted, even when zero.
For example, 64496:4294967295:2 or 64496:0:0.
Vendors MAY provide other textual representations. Vendors MAY provide other textual representations. For example, a
vendor's routing policy language may use a separator other than a
colon or may require keywords or characters prepending or postpending
the Large Communities attribute. Such differences are permitted.
However, each implementation MUST make a representation available
that depicts the integers in decimal and in the following order:
Global Administrator, Local Data Part 1, Local Data Part 2.
4. Error Handling 5. Reserved Large BGP Community values
The error handling of Large Community is as follows: The Large BGP Community attribute values in the following ranges are
reserved:
o A Large Community BGP Path Attribute with a length of zero MUST be 0:0:0 - 0:4294967295:4294967295
ignored upon receipt and removed when sending. 65535:0:0 - 65535:4294967295:4294967295
4294967295:0:0 - 4294967295:4294967295:4294967295
o A Large Community attribute SHALL be considered malformed if its 6. Error Handling
The error handling of Large Communities is as follows:
o A Large Communities BGP Path Attribute with a length of zero MUST
be ignored upon receipt and removed when sending.
o A Large Communities attribute SHALL be considered malformed if its
length is not a non-zero multiple of 12 bytes. length is not a non-zero multiple of 12 bytes.
o A BGP UPDATE message with a malformed Large Community 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].
5. Security Considerations The BGP Large Communities Global Administrator field may contain any
value, and a Large Communities attribute MUST NOT be considered
malformed if the Global Administrator field contains an unallocated,
unassigned or reserved ASN or is set to one of the reserved Large BGP
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
This extension to BGP has similar security implications as BGP This extension to BGP has similar security implications as BGP
Communities [RFC1997]. Communities [RFC1997] and BGP Extended Communities [RFC4360].
underlying security issues. Specifically, an AS relying on the BGP This document does not change any underlying security issues
attributes carried in BGP must have trust in every AS in the path to associated with any other BGP Communities mechanism. Specifically,
the source of the route, as any AS in the path may have altered or an AS relying on the Large BGP Community attribute carried in BGP
deleted attributes or added false attributes. Specifying the must have trust in every other AS in the path, as any intermediate
mechanism(s) to provide such trust is beyond the scope of this Autonomous System in the path may have added, deleted or altered the
document. Large BGP Community attribute. Specifying the mechanism to provide
such trust is beyond the scope of this document.
6. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION Network administrators should note the recommendations in Section 11
of BGP Operations and Security [RFC7454].
8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not supplied by IETF contributors. This is not intended as, and must not
skipping to change at page 5, line 41 skipping to change at page 6, line 19
As of today these vendors have produced an implementation of Large As of today these vendors have produced an implementation of Large
BGP Community: BGP Community:
o Cisco IOS XR o Cisco IOS XR
o ExaBGP o ExaBGP
o GoBGP o GoBGP
o BIRD
The latest implementation news is tracked at The latest implementation news is tracked at
http://largebgpcommunities.net/ [1]. http://largebgpcommunities.net/ [1].
7. IANA Considerations 9. IANA Considerations
IANA is requested to assign a BGP path attribute value for the Large IANA has assigned value 30 (LARGE_COMMUNITY Attribute) in the "BGP
Community attribute. Path Attributes" sub-registry under the "Border Gateway Protocol
(BGP) Parameters" registry.
8. Acknowledgements 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,
Pier Carlo Chiodi, Nabeel Cocker, Ian Dickinson, Jan Baggen, Duncan Pier Carlo Chiodi, Nabeel Cocker, Ian Dickinson, Jan Baggen, Duncan
Lockwood, David Farmer, Randy Bush, Wim Henderickx, Stefan Plug, Kay Lockwood, David Farmer, Randy Bush, Wim Henderickx, Stefan Plug, Kay
Rechthien, Rob Shakir, Warren Kumari, Gert Doering, Thomas King, Rechthien, Rob Shakir, Warren Kumari, Gert Doering, Thomas King,
Mikael Abrahamsson, Wesley Steehouwer, Sander Steffann, Brad Mikael Abrahamsson, Wesley Steehouwer, Sander Steffann, Brad
Dreisbach, Martin Millnert, Christopher Morrow, Jay Borkenhagen, Dreisbach, Martin Millnert, Christopher Morrow, Jay Borkenhagen,
Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner, Tom Daly, Ben Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner, Tom Daly, Ben
Maddison, Alexander Azimov, Brian Dickson and Peter van Dijk for Maddison, Alexander Azimov, Brian Dickson, Peter van Dijk, Julian
their support, insightful review and comments. Seifert, Tom Petch and Tom Scholl for their support, insightful
review and comments.
9. References 11. References
9.1. Normative References 11.1. Normative References
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<http://www.rfc-editor.org/info/rfc1997>. <http://www.rfc-editor.org/info/rfc1997>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793, Autonomous System (AS) Number Space", RFC 6793,
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>.
9.2. Informative References 11.2. Informative References
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Specifications: ABNF", STD 68, RFC 5234, Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
DOI 10.17487/RFC5234, January 2008, February 2006, <http://www.rfc-editor.org/info/rfc4360>.
<http://www.rfc-editor.org/info/rfc5234>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
and Security", BCP 194, RFC 7454, DOI 10.17487/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>.
9.3. URIs 11.3. URIs
[1] https://largebgpcommunities.net [1] https://largebgpcommunities.net
Authors' Addresses Authors' Addresses
Jakob Heitz Jakob Heitz
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95054 San Jose, CA 95054
USA USA
Email: jheitz@cisco.com Email: jheitz@cisco.com
Keyur Patel Keyur Patel
Arrcus, Inc Arrcus, Inc
 End of changes. 50 change blocks. 
118 lines changed or deleted 151 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/