draft-ietf-l3vpn-acceptown-community-10.txt   rfc7611.txt 
Network Working Group J. Uttaro Internet Engineering Task Force (IETF) J. Uttaro
Internet-Draft ATT Request for Comments: 7611 AT&T
Intended status: Standards Track P. Mohapatra Category: Standards Track P. Mohapatra
Expires: December 26, 2015 Sproute Networks ISSN: 2070-1721 Sproute Networks
D. Smith D. Smith
Cisco Systems Cisco Systems
R. Raszuk R. Raszuk
Mirantis Inc. Mirantis Inc.
J. Scudder J. Scudder
Juniper Networks Juniper Networks
June 24, 2015 August 2015
BGP ACCEPT_OWN Community Attribute BGP ACCEPT_OWN Community Attribute
draft-ietf-l3vpn-acceptown-community-10.txt
Abstract Abstract
Under certain conditions it is desirable for a Border Gateway Under certain conditions, it is desirable for a Border Gateway
Protocol (BGP) route reflector to be able to modify the Route Target Protocol (BGP) route reflector to be able to modify the Route Target
(RT) list of a Virtual Private Network (VPN) route that the route (RT) list of a Virtual Private Network (VPN) route that the route
reflector distributes, enabling the route reflector to control how a reflector distributes, enabling the route reflector to control how a
route originated within one Virtual Routing and Forwarding (VRF) is route originated within one VPN Routing and Forwarding table (VRF) is
imported into other VRFs. This technique works effectively as long imported into other VRFs. This technique works effectively as long
as the VRF that exports the route is not on the same Provider Edge as the VRF that exports the route is not on the same Provider Edge
(PE) router than the VRF(s) that import the route. However, due to (PE) router as the VRF(s) that imports the route. However, due to
the constraints of the BGP protocol, it does not work if the two are the constraints of BGP, it does not work if the two are on the same
on the same PE. This document describes a modification to the BGP PE. This document describes a modification to BGP allowing this
protocol allowing this technique to work when the VRFs are on the technique to work when the VRFs are on the same PE and to be used in
same PE, and to be used in a standard manner throughout an autonomous a standard manner throughout an autonomous system.
system.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on December 26, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7611.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 2, line 26 skipping to change at page 2, line 26
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. ACCEPT_OWN Community . . . . . . . . . . . . . . . . . . . . 3 2. ACCEPT_OWN Community . . . . . . . . . . . . . . . . . . . . 3
2.1. Route Acceptance . . . . . . . . . . . . . . . . . . . . 3 2.1. Route Acceptance . . . . . . . . . . . . . . . . . . . . 3
2.2. Propagating ACCEPT_OWN Between Address Families . . . . . 4 2.2. Propagating ACCEPT_OWN between Address Families . . . . . 4
2.3. Configuration Control . . . . . . . . . . . . . . . . . . 4 2.3. Configuration Control . . . . . . . . . . . . . . . . . . 4
3. Decision Process . . . . . . . . . . . . . . . . . . . . . . 4 3. Decision Process . . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 5
5. Other Applications . . . . . . . . . . . . . . . . . . . . . 5 5. Other Applications . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Local Extranet Application (non-normative) . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Local Extranet Application (Non-normative) . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
In certain scenarios, a BGP speaker may maintain multiple VRFs In certain scenarios, a BGP speaker may maintain multiple VRFs
[RFC4364]. Under certain conditions, it is desirable for a route [RFC4364]. Under certain conditions, it is desirable for a route
reflector to be able to modify the RT list of a VPN route that the reflector to be able to modify the RT list of a VPN route that the
route reflector distributes, enabling the route reflector to control route reflector distributes, enabling the route reflector to control
how a route originated within one VRF is imported into other VRFs. how a route originated within one VRF is imported into other VRFs.
Though it is possible to perform such policy control directly on the Though it is possible to perform such control directly on the
originator, it may be operationally cumbersome in an autonomous originator, it may be operationally cumbersome in an autonomous
system with a large number of border routers having complex BGP system with a large number of border routers having complex BGP
policies. policies.
The technique of the route reflector modifying the RT list works The technique of the route reflector modifying the RT list works
effectively as long as the VRF that exports the route is not on the effectively as long as the VRF that exports the route is not on the
same PE as the VRF(s) that import the route. However, due to the same PE as the VRF(s) that imports the route. However, due to
constraints of the BGP protocol, it does not work if the two are on constraints of BGP, it does not work if the two are on the same PE.
the same PE. This is because per the BGP specification [RFC4271], a This is because, per the BGP specification [RFC4271], a BGP speaker
BGP speaker rejects prefix advertisements received that were rejects received prefix advertisements that were originated by
originated by itself. In an autonomous system with route reflectors, itself. In an autonomous system with route reflectors, the route
the route reflector attaches the ORIGINATOR_ID attribute to the reflector attaches the ORIGINATOR_ID attribute to the UPDATE messages
UPDATE messages so that if such prefix advertisements reach the so that if such prefix advertisements reach the originator, the
originator, the originator can reject them by simply checking the originator can reject them by simply checking the ORIGINATOR_ID
ORIGINATOR_ID attribute. The BGP specification also mandates that a attribute. The BGP specification also mandates that a route should
route should not be accepted from a peer when the NEXT_HOP attribute not be accepted from a peer when the NEXT_HOP attribute matches the
matches the receiver's own "IP address". receiver's own IP address.
This document proposes a modification to BGP's behavior by defining a This document proposes a modification to BGP's behavior by defining a
new community [RFC1997] value, in order to allow the technique of RT new community [RFC1997] value, in order to allow the technique of RT
list modification by the route reflector to be used in a standard list modification by the route reflector to be used in a standard
manner throughout an autonomous system, irrespective of whether the manner throughout an autonomous system, irrespective of whether or
VRFs are on the same, or different PEs. not the VRFs are on the same or different PEs.
1.1. Requirements Language 1.1. 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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. ACCEPT_OWN Community 2. ACCEPT_OWN Community
This memo defines a new well-known BGP community from the First Come This memo defines ACCEPT_OWN, a new well-known BGP community in the
First Served range, ACCEPT_OWN, whose value as assigned by IANA is First Come First Served [RFC5226] range, whose value as assigned by
0xFFFF0001. Processing of the ACCEPT_OWN community SHOULD be IANA is 0xFFFF0001. Processing of the ACCEPT_OWN community SHOULD be
controlled by configuration. The functionality SHOULD default to controlled by configuration. The functionality SHOULD default to
being disabled, as further specified in Section 2.3. being disabled, as further specified in Section 2.3.
2.1. Route Acceptance 2.1. Route Acceptance
A router MAY accept a route whose ORIGINATOR_ID or NEXT_HOP value A router MAY accept a route whose ORIGINATOR_ID or NEXT_HOP value
matches that of the receiving speaker if all of the following are matches that of the receiving speaker if all of the following are
true: true:
o Processing of the ACCEPT_OWN community is enabled by o Processing of the ACCEPT_OWN community is enabled by
configuration. configuration.
o The route in question carries the ACCEPT_OWN community. o The route in question carries the ACCEPT_OWN community.
o The route in question was originated from a source VRF on the o The route in question originated from a source VRF on the router.
router. The source VRF is a VRF on the router whose configured The source VRF is a VRF on the router whose configured Route
Route Distinguisher is equal to the Route Distinguisher carried in Distinguisher is equal to the Route Distinguisher carried in the
the route. route.
o The route in question is targeted to one or more destination VRFs o The route in question is targeted to one or more destination VRFs
on the router (as determined by inspecting the Route Target(s)). on the router (as determined by inspecting the Route Target(s)).
o At least one destination VRF is different from the source VRF. o At least one destination VRF is different from the source VRF.
A route MUST NOT ever be accepted back into its source VRF, even if A route MUST NOT ever be accepted back into its source VRF, even if
it carries one or more RTs which match that VRF. it carries one or more RTs that match that VRF.
2.2. Propagating ACCEPT_OWN Between Address Families 2.2. Propagating ACCEPT_OWN between Address Families
The ACCEPT_OWN community controls propagation of routes which can be The ACCEPT_OWN community controls propagation of routes that can be
associated with a source VRF by inspection of their Route associated with a source VRF by inspection of their Route
Distinguisher and with a target VRF by inspection of their Route Distinguisher and with a target VRF by inspection of their Route
Target list (for example VPN routes with a SAFI of 128). As such, it Target list (for example, VPN routes with a Subsequent Address Family
SHOULD NOT be attached to any routes which cannot be associated with Identifier (SAFI) of 128). As such, it SHOULD NOT be attached to any
a source VRF. This implies that when propagating routes into a VRF, routes that cannot be associated with a source VRF. This implies
the ACCEPT_OWN community SHOULD NOT be propagated. Likewise, if a that when propagating routes into a VRF, the ACCEPT_OWN community
route carrying the ACCEPT_OWN community is received in an address SHOULD NOT be propagated. Likewise, if a route carrying the
family which does not allow the source VRF to be looked up, the ACCEPT_OWN community is received in an address family that does not
ACCEPT_OWN community MUST be discarded. An OPTIONAL message may be allow the source VRF to be looked up, the ACCEPT_OWN community MUST
logged in this case. be discarded. An OPTIONAL message may be logged in this case.
2.3. Configuration Control 2.3. Configuration Control
ACCEPT_OWN handling SHOULD be controlled by configuration, and if ACCEPT_OWN handling SHOULD be controlled by configuration, and if
controlled by configuration, it MUST default to being disabled. When controlled by configuration, it MUST default to being disabled. When
ACCEPT_OWN is disabled by configuration (either explicitly or by ACCEPT_OWN is disabled by configuration (either explicitly or by
default), the router MUST NOT apply the special route acceptance default), the router MUST NOT apply the special route acceptance
rules detailed in Section 2.1. The router SHOULD still apply the rules detailed in Section 2.1. The router SHOULD still apply the
propagation rules detailed in Section 2.2. propagation rules detailed in Section 2.2.
3. Decision Process 3. Decision Process
If a BGP speaker supports ACCEPT_OWN and is configured for the If a BGP speaker supports ACCEPT_OWN and is configured for the
extensions defined in this document, the following step is inserted extensions defined in this document, the following step is inserted
after the LOCAL_PREF comparison step in BGP decision process: after the LOCAL_PREF comparison step in the BGP decision process:
When comparing a pair of routes for a BGP destination, the route When comparing a pair of routes for a BGP destination, the route
attached with ACCEPT_OWN community is preferred over the route with the ACCEPT_OWN community attached is preferred over the route
that does not have the community. that does not have the community.
In all other respects, the decision process remains unchanged. This In all other respects, the decision process remains unchanged. This
extra step MUST only be invoked during the best path selection extra step MUST only be invoked during the best path selection
process of VPN-IP routes [RFC4364] (i.e., it MUST NOT be invoked for process of VPN-IP routes [RFC4364] (i.e., it MUST NOT be invoked for
the best path selection of "imported" IP routes in a VRF). The the best path selection of imported IP routes in a VRF). The purpose
purpose of the extra step is to allow the paths advertised by the of this extra step is to allow the paths advertised by the route
route reflector with ACCEPT_OWN community to be selected as best over reflector with ACCEPT_OWN community to be selected as best over other
other paths that the BGP speaker may have received, hence enabling paths that the BGP speaker may have received, hence enabling the
the applications ACCEPT_OWN is designed for. applications ACCEPT_OWN is designed for.
4. Deployment Considerations 4. Deployment Considerations
The ACCEPT_OWN community as described in this document is useful The ACCEPT_OWN community as described in this document is useful
within a single autonomous system which uses a single layer of route within a single autonomous system that uses a single layer of route
reflectors. Its use with hierarchical route reflectors would require reflectors. Its use with hierarchical route reflectors would require
further specification and is out of scope for this document. further specification and is out of the scope of this document.
Likewise, its use across multiple autonomous systems is out of scope Likewise, its use across multiple autonomous systems is out of the
for this document. scope of this document.
5. Other Applications 5. Other Applications
This approach may also be relevant to other scenarios where a BGP This approach may also be relevant in other scenarios where a BGP
speaker maintains multiple routing contexts using an approach speaker maintains multiple routing contexts using an approach
different from that of [RFC4364], as long as the specific approach in different from that of [RFC4364], as long as the specific approach in
use has the property that the BGP speaker originates and receives use has the property that the BGP speaker originates and receives
routes within a particular context. In such a case, "VRF" in this routes within a particular context. In such a case, "VRF" in this
document should be understood to mean whatever construct provides a document should be understood to mean whatever construct provides a
routing context in the specific technology under consideration. routing context in the specific technology under consideration.
Likewise, "Route Distinguisher" should be understood to mean whatever Likewise, "Route Distinguisher" should be understood to mean whatever
construct allows a route's originator to associate that route with construct allows a route's originator to associate that route with
its source context, and "Route Target" should be understood to mean its source context, and "Route Target" should be understood to mean
whatever construct allows a route to be targeted for import into a whatever construct allows a route to be targeted for import into a
context other than its source. context other than its source.
6. Security Considerations 6. Security Considerations
ACCEPT_OWN as described above permits a router's own route prefix to ACCEPT_OWN as described in this document permits a router's own route
be advertised to a different VRF on that router. In this respect, prefix to be advertised to a different VRF on that router. In this
such a route is similar to any other BGP route and shares the same respect, such a route is similar to any other BGP route and shares
set of security vulnerabilities and concerns. This extension does the same set of security vulnerabilities and concerns. This
not change the underlying security issues inherent in BGP VPN extension does not change the underlying security issues inherent in
[RFC4364]. BGP VPN [RFC4364].
7. IANA Considerations 7. IANA Considerations
IANA has assigned the value 0xFFFF0001 from BGP well-known IANA has assigned the value 0xFFFF0001 in the "BGP Well-known
communities registry for ACCEPT_OWN community. No additional IANA Communities" registry for the ACCEPT_OWN community.
action is required.
8. Acknowledgments
The authors would like to thank Yakov Rekhter, Jim Guichard, Clarence 8. References
Filsfils, John Mullooly, Jeff Haas, Pranav Mehta, and Tamas Mondal
for their valuable comments and suggestions. The decision process
changes were suggested by Pranav Mehta to solve the remote extranet
problem.
9. Normative References 8.1. Normative References
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Communities Attribute", RFC 1997, August 1996. Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Protocol 4 (BGP-4)", RFC 4271, January 2006. Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>.
Appendix A. Local Extranet Application (non-normative) 8.2. Informative References
One of the applications for this behavior is auto-configuration of [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
extranets within MPLS VPN networks. Consider the following topology: IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
Appendix A. Local Extranet Application (Non-normative)
One of the applications for the BGP well-known community described in
this document is auto-configuration of extranets within MPLS VPN
networks. Consider the following topology:
CE1 --------+ CE1 --------+
| |
(VRF 1, RD 1, RT 1) (VRF 1, RD 1, RT 1)
PE1 ................... RR PE1 ................... RR
(VRF 2, RD 2, RT 2) (VRF 2, RD 2, RT 2)
| |
CE2 --------+ CE2 --------+
Figure 1: Extranet Application Figure 1: Extranet Application
Within the above topology, PE1 receives a prefix X from CE1. Prefix Within this topology, PE1 receives a prefix X from CE1. Prefix X is
X is installed in VRF 1 and is advertised to the route reflector with installed in VRF 1 and is advertised to the route reflector (RR) with
route distinguisher (RD) 1 and route target (RT) 1 as configured on Route Distinguisher (RD) 1 and Route Target (RT) 1 as configured on
PE1. The requirement is to import prefix X into VRF 2 and advertise PE1. The requirement is to import prefix X into VRF 2 and advertise
it to CE2 in support of extranet VPN connectivity between CE1/VRF1 it to CE2 in support of extranet VPN connectivity between CE1/VRF1
and CE2/VRF2. Current BGP mechanisms for MPLS VPNs[RFC4364] require and CE2/VRF2. Current BGP mechanisms for MPLS VPNs [RFC4364] require
changing the import RT value and/or import policy for VRF 2 on PE1. changing the import RT value and/or import policy for VRF 2 on PE1.
This is operationally cumbersome in a network with a large number of This is operationally cumbersome in a network with a large number of
border routers having complex BGP policies. border routers having complex BGP policies.
Alternatively, using the new ACCEPT_OWN community value, the route Alternatively, using the new ACCEPT_OWN community value, the route
reflector can simply re-advertise prefix X back to PE1 with RT 2 reflector can simply re-advertise prefix X back to PE1 with RT 2
appended. In this way, PE1 will accept prefix X despite its appended. In this way, PE1 will accept prefix X despite its
ORIGINATOR_ID or NEXT_HOP value, import it into VRF 2 as a result of ORIGINATOR_ID or NEXT_HOP value, import it into VRF 2 as a result of
RT 2, and will then determine the correct adjacency rewrite within the presence of RT 2 in the route's Extended Community path
VRF 1 based on the RD value (1) and the prefix. Note that the RT 1 attribute, and then determine the correct adjacency rewrite within
value originally attached to the route will simply be ignored since VRF 1 based on the RD value and the prefix. Note that the presence
associated with the source VRF 1. The same operation needs also to of RT 1 in the route's Extended Community path attribute will simply
happen in the reverse direction (VRF 1 learning a route from VRF 2) be ignored since RT 1 is associated with the source VRF 1. The same
to achieve establishment of an extranet VPN strictly via the route operation also needs to happen in the reverse direction (VRF 1
reflector without changing the BGP policy of PE1 in any way. learning a route from VRF 2) to achieve establishment of an extranet
VPN strictly via the route reflector without changing the BGP policy
of PE1 in any way.
A router performing such an extranet application can accept a route A router performing such an extranet application can accept a route
with its own ORIGINATOR_ID or NEXT_HOP value only if the VRF in which with its own ORIGINATOR_ID or NEXT_HOP value only if the VRF in which
the router originated the route is different than the VRF in which the router originated the route is different from the VRF in which
the router accepts the re-advertised route. the router accepts the re-advertised route.
Acknowledgments
The authors would like to thank Yakov Rekhter, Jim Guichard, Clarence
Filsfils, John Mullooly, Jeff Haas, Pranav Mehta, and Tamas Mondal
for their valuable comments and suggestions. The decision process
changes were suggested by Pranav Mehta to solve the remote extranet
problem.
Authors' Addresses Authors' Addresses
James Uttaro James Uttaro
ATT AT&T
200 S. Laurel Avenue 200 S. Laurel Avenue
Middletown, NJ 07748 Middletown, NJ 07748
USA United States
Email: uttaro@att.com Email: uttaro@att.com
Pradosh Mohapatra Pradosh Mohapatra
Sproute Networks Sproute Networks
Email: mpradosh@yahoo.com Email: mpradosh@yahoo.com
David J. Smith David J. Smith
Cisco Systems Cisco Systems
111 Wood Avenue South 111 Wood Avenue South
Iselin, NJ 08830 Iselin, NJ 08830
USA United States
Email: djsmith@cisco.com Email: djsmith@cisco.com
Robert Raszuk Robert Raszuk
Mirantis Inc. Mirantis Inc.
615 National Ave. #100 615 National Ave. #100
Mt View, CA 94043 Mountain View, CA 94043
USA United States
Email: robert@raszuk.net Email: robert@raszuk.net
John Scudder John Scudder
Juniper Networks Juniper Networks
1194 N. Mathilda Ave 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA United States
Email: jgs@juniper.net Email: jgs@juniper.net
 End of changes. 49 change blocks. 
125 lines changed or deleted 135 lines changed or added

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