draft-ietf-bess-evpn-ipvpn-interworking-01.txt   draft-ietf-bess-evpn-ipvpn-interworking-02.txt 
skipping to change at page 1, line 21 skipping to change at page 1, line 21
J. Drake J. Drake
W. Lin W. Lin
Juniper Juniper
J. Uttaro J. Uttaro
AT&T AT&T
A. Simpson A. Simpson
Nokia Nokia
Expires: March 5, 2020 September 2, 2019 Expires: June 1, 2020 November 29, 2019
EVPN Interworking with IPVPN EVPN Interworking with IPVPN
draft-ietf-bess-evpn-ipvpn-interworking-01 draft-ietf-bess-evpn-ipvpn-interworking-02
Abstract Abstract
EVPN is used as a unified control plane for tenant network intra and EVPN is used as a unified control plane for tenant network intra and
inter-subnet forwarding. When a tenant network spans not only EVPN inter-subnet forwarding. When a tenant network spans not only EVPN
domains but also domains where IPVPN provides inter-subnet domains but also domains where IPVPN provides inter-subnet
forwarding, there is a need to specify the interworking aspects forwarding, there is a need to specify the interworking aspects
between both EVPN and IPVPN domains, so that the end to end tenant between both EVPN and IPVPN domains, so that the end to end tenant
connectivity can be accomplished. This document specifies how EVPN connectivity can be accomplished. This document specifies how EVPN
should interwork with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families should interwork with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 5, 2020. This Internet-Draft will expire on June 1, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 6, line 10 skipping to change at page 6, line 10
o RT-2: Route Type 2 or MAC/IP route, as per [RFC7432]. o RT-2: Route Type 2 or MAC/IP route, as per [RFC7432].
o RT-5: Route Type 5 or IP Prefix route, as per [IP-PREFIX]. o RT-5: Route Type 5 or IP Prefix route, as per [IP-PREFIX].
o Domain: Two PEs are in the same domain if they are attached to the o Domain: Two PEs are in the same domain if they are attached to the
same tenant and the packets between them do not require a data path same tenant and the packets between them do not require a data path
IP lookup (in the tenant space) in any intermediate router. A IP lookup (in the tenant space) in any intermediate router. A
gateway PE is always configured with multiple Domain-IDs. gateway PE is always configured with multiple Domain-IDs.
Example 1: Figure 4 depicts an example where TS1 and TS2 belong to Example 1: Figure 2 depicts an example where TS1 and TS2 belong to
the same tenant, and they are located in different Data Centers the same tenant, and they are located in different Data Centers
that are connected by gateway PEs (see the gateway PE definition that are connected by gateway PEs (see the gateway PE definition
later). These gateway PEs use IPVPN in the WAN. When TS1 sends later). These gateway PEs use IPVPN in the WAN. When TS1 sends
traffic to TS2, the intermediate routers between PE1 and PE2 traffic to TS2, the intermediate routers between PE1 and PE2
require a tenant IP lookup in their IP-VRFs so that the packets can require a tenant IP lookup in their IP-VRFs so that the packets can
be forwarded. In this example there are three different domains. be forwarded. In this example there are three different domains.
The gateway PEs connect the EVPN domains to the IPVPN domain. The gateway PEs connect the EVPN domains to the IPVPN domain.
GW1------------GW3 GW1------------GW3
+------+ +------+ +------+ +------+
skipping to change at page 6, line 33 skipping to change at page 6, line 33
+------+ DC1 | WAN | DC2 +------+ +------+ DC1 | WAN | DC2 +------+
TS1-|IP-VRF| EVPN | IPVPN | EVPN |IP-VRF|-TS2 TS1-|IP-VRF| EVPN | IPVPN | EVPN |IP-VRF|-TS2
+------+ GW2 GW4 +---+--+ +------+ GW2 GW4 +---+--+
| +------+ +------+ | | +------+ +------+ |
+-------------|IP-VRF| |IP-VRF|-------------+ +-------------|IP-VRF| |IP-VRF|-------------+
+------+ +------+ +------+ +------+
+--------------+ +--------------+
DOMAIN 1 DOMAIN 2 DOMAIN 3 DOMAIN 1 DOMAIN 2 DOMAIN 3
<---------------> <------------> <----------------> <---------------> <------------> <---------------->
Figure 4 Multiple domain DCI example Figure 2 Multiple domain DCI example
Example 2: Figure 5 illustrates a similar example, but PE1 and PE2 Example 2: Figure 3 illustrates a similar example, but PE1 and PE2
are now connected by a BGP-LU (BGP Labeled Unicast) tunnel, and are now connected by a BGP-LU (BGP Labeled Unicast) tunnel, and
they have a BGP peer relationship for EVPN. Contrary to Example 1, they have a BGP peer relationship for EVPN. Contrary to Example 1,
there is no need for tenant IP lookups on the intermediate routers there is no need for tenant IP lookups on the intermediate routers
in order to forward packets between PE1 and PE2. Therefore, there in order to forward packets between PE1 and PE2. Therefore, there
is only one domain in the network and PE1/PE2 belong to it. is only one domain in the network and PE1/PE2 belong to it.
EVPN EVPN
<-------------------------------------------------> <------------------------------------------------->
BGP-LU BGP-LU
<-------------------------------------------------> <------------------------------------------------->
skipping to change at page 7, line 24 skipping to change at page 7, line 24
+------+ DC1 | WAN | DC2 +------+ +------+ DC1 | WAN | DC2 +------+
TS1-|IP-VRF| EVPN | | EVPN |IP-VRF|-TS2 TS1-|IP-VRF| EVPN | | EVPN |IP-VRF|-TS2
+------+ ASBR ASBR +---+--+ +------+ ASBR ASBR +---+--+
| +------+ +------+ | | +------+ +------+ |
+-------------| | | |-------------+ +-------------| | | |-------------+
+------+ +------+ +------+ +------+
+--------------+ +--------------+
<--------------------DOMAIN-1---------------------> <--------------------DOMAIN-1--------------------->
Figure 5 Single domain DCI example Figure 3 Single domain DCI example
o Regular Domain: a domain in which a single control plane, IPVPN or o Regular Domain: a domain in which a single control plane, IPVPN or
EVPN, is used and which is composed of regular PEs, see below. In EVPN, is used and which is composed of regular PEs, see below. In
Figures 4 and 5, above, all domains are regular domains. Figures 2 and 3, above, all domains are regular domains.
o Composite Domain: a domain in which multiple control planes, IPVPN o Composite Domain: a domain in which multiple control planes, IPVPN
and EVPN, are used and which is composed of regular PEs, see below, and EVPN, are used and which is composed of regular PEs, see below,
and composite PEs, see below. and composite PEs, see below.
o Regular PE: a PE that is attached to a domain, either regular or o Regular PE: a PE that is attached to a domain, either regular or
composite, and which uses one of the control plane protocols (IPVPN composite, and which uses one of the control plane protocols (IPVPN
or EVPN) operating in the domain. or EVPN) operating in the domain.
o Interworking PE: a PE that may advertise a given prefix with an o Interworking PE: a PE that may advertise a given prefix with an
skipping to change at page 8, line 11 skipping to change at page 8, line 11
ISF SAFIs 1, 128 and 70 are enabled. IP-VRF1 and MAC-VRF1 are ISF SAFIs 1, 128 and 70 are enabled. IP-VRF1 and MAC-VRF1 are
instantiated on the PE, and together provide inter-subnet instantiated on the PE, and together provide inter-subnet
forwarding for the tenant. forwarding for the tenant.
o Composite PE: an interworking PE that is attached to a composite o Composite PE: an interworking PE that is attached to a composite
domain and which advertises a given prefix to an IPVPN peer with an domain and which advertises a given prefix to an IPVPN peer with an
IPVPN ISF route, to an EVPN peer with an EVPN ISF route, and to a IPVPN ISF route, to an EVPN peer with an EVPN ISF route, and to a
route reflector with both an IPVPN and EVPN ISF route. A composite route reflector with both an IPVPN and EVPN ISF route. A composite
PE performs the procedures of Sections 5 and 6. PE performs the procedures of Sections 5 and 6.
Example: Figure 2 shows an example where PE1 is a composite PE Example: Figure 4 shows an example where PE1 is a composite PE
since PE1 has EVPN and another ISF SAFI enabled to the same route- since PE1 has EVPN and another ISF SAFI enabled to the same route-
reflector, and PE1 advertises a given IP prefix IPn/x twice, one reflector, and PE1 advertises a given IP prefix IPn/x twice, one
using EVPN and another one using ISF SAFI 128. PE2 and PE3 are not using EVPN and another one using ISF SAFI 128. PE2 and PE3 are not
composite PEs. composite PEs.
+---+ +---+
|PE2| |PE2|
+---+ +---+
^ ^
|EVPN |EVPN
IW EVPN v IW EVPN v
+---+ IPVPN ++-+ +---+ +---+ IPVPN ++-+ +---+
|PE1| <----> |RR| <---> |PE3| |PE1| <----> |RR| <---> |PE3|
+---+ +--+ IPVPN +---+ +---+ +--+ IPVPN +---+
Composite Composite
Figure 2 Interworking composite PE example Figure 4 Interworking composite PE example
o Gateway PE: an interworking PE that is attached to two domains, o Gateway PE: an interworking PE that is attached to two domains,
each either regular or composite, and which, based on each either regular or composite, and which, based on
configuration, does one of the following: configuration, does one of the following:
- Propagates the same control plane protocol, either IPVPN or EVPN, - Propagates the same control plane protocol, either IPVPN or EVPN,
between the two domains. between the two domains.
- Propagates an ISF route with different ISF SAFIs between the two - Propagates an ISF route with different ISF SAFIs between the two
domains. E.g., propagate an EVPN ISF route in one domain as an domains. E.g., propagate an EVPN ISF route in one domain as an
IPVPN ISF route in the other domain and vice versa. A gateway PE IPVPN ISF route in the other domain and vice versa. A gateway PE
performs the procedures of Sections 3, 4, 5 and 7. performs the procedures of Sections 3, 4, 5 and 7.
A gateway PE is always configured with multiple Domain-IDs. The A gateway PE is always configured with multiple Domain-IDs. The
Domain-ID is encoded in the Domain Path Attribute (D-PATH), and Domain-ID is encoded in the Domain Path Attribute (D-PATH), and
advertised along with EVPN and other ISF SAFI routes. Section 3 advertised along with EVPN and other ISF SAFI routes. Section 3
describes the D-PATH attribute. describes the D-PATH attribute.
Example: Figure 3 illustrates an example where PE1 is a gateway Example: Figure 5 illustrates an example where PE1 is a gateway
PE since the EVPN and IPVPN SAFIs are enabled on different BGP PE since the EVPN and IPVPN SAFIs are enabled on different BGP
peers, and a given local IP prefix IPn/x is sent to both BGP peers, and a given local IP prefix IPn/x is sent to both BGP
peers for the same tenant. PE2 and PE1 are in one domain and PE3 peers for the same tenant. PE2 and PE1 are in one domain and PE3
and PE1 are in another domain. and PE1 are in another domain.
IW IW
+---+ EVPN +---+ IPVPN +---+ +---+ EVPN +---+ IPVPN +---+
|PE2| <----> |PE1| <----> |PE3| |PE2| <----> |PE1| <----> |PE3|
+---+ +---+ +---+ +---+ +---+ +---+
Gateway Gateway
Figure 3 Interworking gateway PE example Figure 5 Interworking gateway PE example
o Composite/Gateway PE: an interworking PE that is both a composite o Composite/Gateway PE: an interworking PE that is both a composite
PE and a gateway PE that is attached to two domains, one regular PE and a gateway PE that is attached to two domains, one regular
and one composite, and which does the following: and one composite, and which does the following:
- Propagates an ISF route, either IPVPN or EVPN, from the regular - Propagates an ISF route, either IPVPN or EVPN, from the regular
domain into the composite domain. Within the composite domain it domain into the composite domain. Within the composite domain it
acts as a composite PE. acts as a composite PE.
- Propagates an ISF route, either IPVPN or EVPN, from the composite - Propagates an ISF route, either IPVPN or EVPN, from the composite
skipping to change at page 9, line 41 skipping to change at page 9, line 41
It would be instantiated by attaching the disparate, regular It would be instantiated by attaching the disparate, regular
IPVPN and EVPN domains via these PEs to a central composite IPVPN and EVPN domains via these PEs to a central composite
domain. domain.
3. Domain Path Attribute (D-PATH) 3. Domain Path Attribute (D-PATH)
The BGP Domain Path (D-PATH) attribute is an optional and transitive The BGP Domain Path (D-PATH) attribute is an optional and transitive
BGP path attribute. BGP path attribute.
Similar to AS_PATH, D-PATH is composed of a length field followed by Similar to AS_PATH, D-PATH is composed of a sequence of Domain
a sequence of Domain segments, where each domain segment is segments. Each Domain segment is comprised of <domain segment length,
represented by <DOMAIN-ID:ISF_SAFI_TYPE>. domain segment value>, where the domain segment value is a sequence
of one or more Domains. Each domain is represented by <DOMAIN-
ID:ISF_SAFI_TYPE>.
o The length field is a 1-octet field, containing the number of o The domain segment length field is a 1-octet field, containing the
domain segments. number of domains in the segment.
o DOMAIN-ID is a 6-octet field that represents a domain. It is o DOMAIN-ID is a 6-octet field that represents a domain. It is
composed of a 4-octet Global Administrator sub-field and a 2-octet composed of a 4-octet Global Administrator sub-field and a 2-octet
Local Administrator sub-field. The Global Administrator sub-field Local Administrator sub-field. The Global Administrator sub-field
MAY be filled with an Autonomous System Number (ASN), an IPv4 MAY be filled with an Autonomous System Number (ASN), an IPv4
address, or any value that guarantees the uniqueness of the DOMAIN- address, or any value that guarantees the uniqueness of the DOMAIN-
ID when the tenant network is connected to multiple Operators. ID when the tenant network is connected to multiple Operators.
o ISF_SAFI_TYPE is a 1-octet field that indicates the Inter-Subnet o ISF_SAFI_TYPE is a 1-octet field that indicates the Inter-Subnet
Forwarding SAFI type in which a route was advertised in the DOMAIN. Forwarding SAFI type in which a route was advertised in the DOMAIN.
skipping to change at page 10, line 27 skipping to change at page 10, line 28
1 SAFI 1 1 SAFI 1
70 EVPN 70 EVPN
128 SAFI 128 128 SAFI 128
About the BGP D-PATH attribute: About the BGP D-PATH attribute:
a) Identifies the sequence of domains, each identified by a <DOMAIN- a) Identifies the sequence of domains, each identified by a <DOMAIN-
ID:ISF_SAFI_TYPE> through which a given ISF route has passed. ID:ISF_SAFI_TYPE> through which a given ISF route has passed.
- This attribute list may contain zero, one or more entries. - This attribute list may contain zero, one or more segments.
- The first entry in the list (leftmost) is the <DOMAIN- - The first entry in the list (leftmost) is the <DOMAIN-
ID:ISF_SAFI_TYPE> from which a gateway PE is propagating an ISF ID:ISF_SAFI_TYPE> from which a gateway PE is propagating an ISF
route. The last entry in the list (rightmost) is the <DOMAIN- route. The last entry in the list (rightmost) is the <DOMAIN-
ID:ISF_SAFI_TYPE> from which a gateway PE received an ISF route ID:ISF_SAFI_TYPE> from which a gateway PE received an ISF route
without a D-PATH attribute. Intermediate entries in the list are without a D-PATH attribute. Intermediate entries in the list are
domains that the ISF route has transited. domains that the ISF route has transited.
- As an example, an ISF route received with a D-PATH attribute of - As an example, an ISF route received with a D-PATH attribute
{<6500:2:IPVPN>,<6500:1:EVPN>} indicates that the ISF route was containing a domain segment of {length=2,
<6500:2:IPVPN>,<6500:1:EVPN>} indicates that the ISF route was
originated in EVPN domain 6500:1, and propagated into IPVPN originated in EVPN domain 6500:1, and propagated into IPVPN
domain 6500:2. domain 6500:2.
b) It is added/modified by a gateway PE when propagating an update to b) It is added/modified by a gateway PE when propagating an update to
a different domain: a different domain:
- A gateway PE's IP-VRF, that connects two domains, belongs to two - A gateway PE's IP-VRF, that connects two domains, belongs to two
DOMAIN-IDs, e.g. 6500:1 for EVPN and 6500:2 for IPVPN. DOMAIN-IDs, e.g. 6500:1 for EVPN and 6500:2 for IPVPN.
- Whenever a prefix arrives at a gateway PE in a particular ISF - Whenever a prefix arrives at a gateway PE in a particular ISF
SAFI route, if the gateway PE needs to export that prefix to a SAFI route, if the gateway PE needs to export that prefix to a
BGP peer, the gateway PE will prepend a <DOMAIN- BGP peer, the gateway PE will prepend a <DOMAIN-
ID:ISF_SAFI_TYPE> segment to the list of segments in the ID:ISF_SAFI_TYPE> to the list of domains in the received D-PATH.
received D-PATH.
- For instance, in an IP-VRF configured with DOMAIN-IDs 6500:1 for - For instance, in an IP-VRF configured with DOMAIN-IDs 6500:1 for
EVPN and 6500:2 for IPVPN, if an EVPN route for prefix P is EVPN and 6500:2 for IPVPN, if an EVPN route for prefix P is
received and P installed in the IP-VRF, the IPVPN route for P received and P installed in the IP-VRF, the IPVPN route for P
that is exported to an IPVPN peer will prepend the segment that is exported to an IPVPN peer will prepend the domain
<6500:1:EVPN> to the previously received D-PATH attribute. <6500:1:EVPN> to the previously received D-PATH attribute.
Likewise, IP-VRF prefixes that are received from IP-VPN, will be Likewise, IP-VRF prefixes that are received from IP-VPN, will be
exported to EVPN peers with the additional segment exported to EVPN peers with the domain <6500:2:IPVPN> added to
<6500:2:IPVPN>. the segment.
- In the above example, if the EVPN route is received without D- - In the above example, if the EVPN route is received without D-
PATH, the gateway PE will add the D-PATH attribute with segment PATH, the gateway PE will add the D-PATH attribute with one
<6500:1:EVPN> when re-advertising to domain 6500:2. segment {length=1, <6500:1:EVPN>} when re-advertising to domain
6500:2.
- Within the originating domain, the update does not contain a D- - Within the originating domain, the update does not contain a D-
PATH attribute because the update has not passed through a PATH attribute because the update has not passed through a
gateway PE yet. gateway PE yet.
c) The gateway PE MUST NOT add the D-PATH attribute to ISF routes c) The gateway PE MUST NOT add the D-PATH attribute to ISF routes
generated for IP-VRF prefixes that are not learned via any ISF generated for IP-VRF prefixes that are not learned via any ISF
SAFI, for instance, local prefixes. SAFI, for instance, local prefixes.
d) An ISF route received by a gateway PE with a D-PATH attribute that d) An ISF route received by a gateway PE with a D-PATH attribute that
contains one or more of its locally configured domains for the IP- contains one or more of its locally configured domains for the IP-
VRF is considered to be a looped ISF route and MUST be dropped. VRF is considered to be a looped ISF route and MUST be dropped.
e) The number of domain segments in the D-PATH attribute indicates e) The number of domains in the D-PATH attribute indicates the number
the number of gateway PEs that the ISF route update has transited. of gateway PEs that the ISF route update has transited.
3.1. D-PATH and Loop Prevention 3.1. D-PATH and Loop Prevention
The D-PATH attribute is used to prevent loops in interworking PE The D-PATH attribute is used to prevent loops in interworking PE
networks. For instance, in the example of Figure 4, gateway GW1 networks. For instance, in the example of Figure 4, gateway GW1
receives TS1 prefix in two different ISF routes: receives TS1 prefix in two different ISF routes:
o In an EVPN RT-5 with next-hop PE1 and no D-PATH attribute. o In an EVPN RT-5 with next-hop PE1 and no D-PATH attribute.
o In a SAFI 128 route with next-hop GW2 and D-PATH = (6500:1:EVPN), o In a SAFI 128 route with next-hop GW2 and D-PATH = {length=1,
assuming that DOMAIN-ID for domain 1 is 6500:1. <6500:1:EVPN>}, assuming that DOMAIN-ID for domain 1 is 6500:1.
Gateway GW1 flags the SAFI 128 route as a loop, and does not re- Gateway GW1 flags the SAFI 128 route as a loop, and does not re-
advertise it to the EVPN neighbors since the route includes the GW1's advertise it to the EVPN neighbors since the route includes the GW1's
local domain. local domain.
In general, any interworking PE that imports an ISF route MUST flag In general, any interworking PE that imports an ISF route MUST flag
the route as "looped" if its D-PATH contains a <DOMAIN- the route as "looped" if its D-PATH contains a <DOMAIN-
ID:ISF_SAFI_TYPE> segment, where DOMAIN-ID matches a local DOMAIN-ID ID:ISF_SAFI_TYPE> segment, where DOMAIN-ID matches a local DOMAIN-ID
in the tenant IP-VRF. in the tenant IP-VRF.
4. BGP Path Attribute Propagation across ISF SAFIs 4. BGP Path Attribute Propagation across ISF SAFIs
Based on configurations a gateway PE is required to propagate an ISF Based on configurations a gateway PE is required to propagate an ISF
route with different ISF SAFIs between two domains. This requires a route with different ISF SAFIs between two domains. This requires a
definition of what a gateway PE is to do with Path attributes definition of what a gateway PE has to do with Path attributes
attached to the ISF route that it is propagating. attached to the ISF route that it is propagating.
4.1. No-Propagation-Mode 4.1. No-Propagation-Mode
This is the default mode of operation. In this mode, the gateway PE This is the default mode of operation. In this mode, the gateway PE
will simply re-initialize the Path Attributes when propagating an ISF will simply re-initialize the Path Attributes when propagating an ISF
route, as though it would for direct or local IP prefixes. This model route, as though it would for direct or local IP prefixes. This model
may be enough in those use-cases where the EVPN domain is considered may be enough in those use-cases where the EVPN domain is considered
an "abstracted" CE and remote IPVPN/IP PEs don't need to consider the an "abstracted" CE and remote IPVPN/IP PEs don't need to consider the
original EVPN Attributes for path calculations. original EVPN Attributes for path calculations.
skipping to change at page 23, line 9 skipping to change at page 23, line 9
draft-ietf-bess-evpn-inter-subnet-forwarding-08.txt, work in draft-ietf-bess-evpn-inter-subnet-forwarding-08.txt, work in
progress, March, 2019. progress, March, 2019.
[RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using
AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, DOI AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, DOI
10.17487/RFC6472, December 2011, <https://www.rfc- 10.17487/RFC6472, December 2011, <https://www.rfc-
editor.org/info/rfc6472>. editor.org/info/rfc6472>.
14. Acknowledgments 14. Acknowledgments
The authors want to thank Russell Kelly for his review of the D-PATH
section and suggestions.
15. Contributors 15. Contributors
16. Authors' Addresses 16. Authors' Addresses
Jorge Rabadan (editor) Jorge Rabadan (editor)
Nokia Nokia
777 E. Middlefield Road 777 E. Middlefield Road
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
 End of changes. 24 change blocks. 
32 lines changed or deleted 38 lines changed or added

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