draft-ietf-bess-mvpn-global-table-mcast-01.txt   draft-ietf-bess-mvpn-global-table-mcast-02.txt 
BESS Working Group Z. Zhang BESS Working Group Z. Zhang
Internet-Draft L. Giuliano Internet-Draft L. Giuliano
Intended status: Standards Track E. Rosen, Ed. Intended status: Standards Track E. Rosen, Ed.
Expires: November 19, 2015 Juniper Networks, Inc. Expires: January 21, 2016 Juniper Networks, Inc.
K. Subramanian K. Subramanian
Cisco Systems, Inc. Cisco Systems, Inc.
D. Pacella D. Pacella
Verizon Verizon
J. Schiller July 20, 2015
Google
May 18, 2015
Global Table Multicast with BGP-MVPN Procedures Global Table Multicast with BGP-MVPN Procedures
draft-ietf-bess-mvpn-global-table-mcast-01 draft-ietf-bess-mvpn-global-table-mcast-02
Abstract Abstract
RFC6513, RFC6514, and other RFCs describe protocols and procedures RFC6513, RFC6514, and other RFCs describe protocols and procedures
which a Service Provider (SP) may deploy in order offer Multicast which a Service Provider (SP) may deploy in order offer Multicast
Virtual Private Network (Multicast VPN or MVPN) service to its Virtual Private Network (Multicast VPN or MVPN) service to its
customers. Some of these procedures use BGP to distribute VPN- customers. Some of these procedures use BGP to distribute VPN-
specific multicast routing information across a backbone network. specific multicast routing information across a backbone network.
With a small number of relatively minor modifications, the very same With a small number of relatively minor modifications, the very same
BGP procedures can also be used to distribute multicast routing BGP procedures can also be used to distribute multicast routing
skipping to change at page 1, line 48 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 November 19, 2015. This Internet-Draft will expire on January 21, 2016.
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 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Adapting MVPN Procedures to GTM . . . . . . . . . . . . . . . 5 2. Adapting MVPN Procedures to GTM . . . . . . . . . . . . . . . 5
2.1. Use of Route Distinguishers . . . . . . . . . . . . . . . 5 2.1. Use of Route Distinguishers . . . . . . . . . . . . . . . 5
2.2. Use of Route Targets . . . . . . . . . . . . . . . . . . 6 2.2. Use of Route Targets . . . . . . . . . . . . . . . . . . 6
2.3. UMH-eligible Routes . . . . . . . . . . . . . . . . . . . 8 2.3. UMH-eligible Routes . . . . . . . . . . . . . . . . . . . 8
2.3.1. Routes of SAFI 1, 2 or 4 with MVPN ECs . . . . . . . 9 2.3.1. Routes of SAFI 1, 2 or 4 with MVPN ECs . . . . . . . 9
2.3.2. MVPN ECs on the Route to the Next Hop . . . . . . . . 10 2.3.2. MVPN ECs on the Route to the Next Hop . . . . . . . . 10
2.3.3. Non-BGP Routes as the UMH-eligible Routes . . . . . . 11 2.3.3. Non-BGP Routes as the UMH-eligible Routes . . . . . . 11
2.3.4. Why SFS Does Not Apply to GTM . . . . . . . . . . . . 11 2.3.4. Why SFS Does Not Apply to GTM . . . . . . . . . . . . 12
2.4. Inclusive and Selective Tunnels . . . . . . . . . . . . . 13 2.4. Inclusive and Selective Tunnels . . . . . . . . . . . . . 13
2.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 13 2.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 13
2.5.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 13 2.5.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 13
2.5.2. Inter-AS I-PMSI A-D Routes . . . . . . . . . . . . . 13 2.5.2. Inter-AS I-PMSI A-D Routes . . . . . . . . . . . . . 14
2.6. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 14 2.6. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 14
2.7. Leaf A-D Routes . . . . . . . . . . . . . . . . . . . . . 14 2.7. Leaf A-D Routes . . . . . . . . . . . . . . . . . . . . . 14
2.8. Source Active A-D Routes . . . . . . . . . . . . . . . . 14 2.8. Source Active A-D Routes . . . . . . . . . . . . . . . . 14
2.8.1. Finding the Originator of an SA A-D Route . . . . . . 14 2.8.1. Finding the Originator of an SA A-D Route . . . . . . 14
2.8.2. Optional Additional Constraints on Distribution . . . 15 2.8.2. Optional Additional Constraints on Distribution . . . 15
2.9. C-multicast Source/Shared Tree Joins . . . . . . . . . . 16 2.9. C-multicast Source/Shared Tree Joins . . . . . . . . . . 16
3. Differences from other MVPN-like GTM Procedures . . . . . . . 16 3. Differences from other MVPN-like GTM Procedures . . . . . . . 17
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. Additional Contributors . . . . . . . . . . . . . . . . . . . 18 6. Additional Contributors . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
[RFC4364] specifies architecture, protocols, and procedures that a [RFC4364] specifies architecture, protocols, and procedures that a
Service Provider (SP) can use to provide Virtual Private Network Service Provider (SP) can use to provide Virtual Private Network
(VPN) service to its customers. In that architecture, one or more (VPN) service to its customers. In that architecture, one or more
Customer Edge (CE) routers attach to a Provider Edge (PE) router. Customer Edge (CE) routers attach to a Provider Edge (PE) router.
Each CE router belongs to a single VPN, but CE routers from several Each CE router belongs to a single VPN, but CE routers from several
VPNs may attach to the same PE router. In addition, CEs from the VPNs may attach to the same PE router. In addition, CEs from the
same VPN may attach to different PEs. BGP is used to carry VPN- same VPN may attach to different PEs. BGP is used to carry VPN-
skipping to change at page 10, line 17 skipping to change at page 10, line 17
Some service providers may consider it to be undesirable to have the Some service providers may consider it to be undesirable to have the
PBRs put the VRF Route Import EC on all the UMH-eligible routes. Or PBRs put the VRF Route Import EC on all the UMH-eligible routes. Or
there may be deployment scenarios in which the UMH-eligible routes there may be deployment scenarios in which the UMH-eligible routes
are not advertised by the PBRs at all. The procedures described in are not advertised by the PBRs at all. The procedures described in
this section provide an alternative that can be used under certain this section provide an alternative that can be used under certain
circumstances. circumstances.
The procedures of this section are OPTIONAL. The procedures of this section are OPTIONAL.
In this alternative procedure, each PBR MUST originate a BGP route of In this alternative procedure, each PBR MUST originate a BGP route of
SAFI 1, 2 or 4 to itself. This route MUST carry a VRF Route Import SAFI 1, 2 or 4 whose NLRI is an IP address of the PBR itself. This
EC that identifies the PBR. The address that appears in the Global route MUST carry a VRF Route Import EC that identifies the PBR. The
Administrator field of that EC MUST be the same address that appears address that appears in the Global Administrator field of that EC
in the NLRI and in the Next Hop field of that route. This route MUST MUST be the same address that appears in the NLRI and in the Next Hop
also carry a Source AS EC identifying the AS of the PBR. field of that route. This route MUST also carry a Source AS EC
identifying the AS of the PBR.
Whenever the PBR distributes a UMH-eligible route for which it sets Whenever the PBR distributes a UMH-eligible route for which it sets
itself as next hop, it MUST use this same IP address as the Next Hop itself as next hop, it MUST use this same IP address as the Next Hop
of the UMH-eligible route that it used in the route discussed in the of the UMH-eligible route that it used in the route discussed in the
prior paragraph. prior paragraph.
When the procedure of his section is used, then when a PBR is When the procedure of his section is used, then when a PBR is
determining the Selected UMH Route for a given multicast flow, it may determining the Selected UMH Route for a given multicast flow, it may
find that the Selected UMH Route has no VRF Route Import EC. In this find that the Selected UMH Route has no VRF Route Import EC. In this
case, the PBR will look up (in the global table) the route to the case, the PBR will look up (in the global table) the route to the
skipping to change at page 13, line 43 skipping to change at page 14, line 5
In addition, a PBR implementing GTM is NOT required to originate an In addition, a PBR implementing GTM is NOT required to originate an
Intra-AS I-PMSI A-D route if both of the following conditions hold: Intra-AS I-PMSI A-D route if both of the following conditions hold:
o The PBR is not using Inclusive Tunnels for GTM, and o The PBR is not using Inclusive Tunnels for GTM, and
o The distribution of the C-multicast Shared Tree Join and o The distribution of the C-multicast Shared Tree Join and
C-multicast Source Tree Join routes is done in such a manner that C-multicast Source Tree Join routes is done in such a manner that
the next hop of those routes does not change. the next hop of those routes does not change.
Please see also the sections on RD and RT usage. Please see also the sections on RD and RT usage (Sections 2.1 and 2.2
respectively).
2.5.2. Inter-AS I-PMSI A-D Routes 2.5.2. Inter-AS I-PMSI A-D Routes
There are no GTM-specific procedures for the origination, There are no GTM-specific procedures for the origination,
distribution, and processing of these routes, other than those distribution, and processing of these routes, other than those
specified in the sections on RD and RT usage. specified in the sections on RD and RT usage.
2.6. S-PMSI A-D Routes 2.6. S-PMSI A-D Routes
There are no GTM-specific procedures for the origination, There are no GTM-specific procedures for the origination,
skipping to change at page 16, line 16 skipping to change at page 16, line 23
Active A-D routes that are about multicast groups in which the PBR Active A-D routes that are about multicast groups in which the PBR
has no interest. has no interest.
This procedure does introduce the overhead of distributing additional This procedure does introduce the overhead of distributing additional
"RT Constraint" routes, and therefore may not be cost-effective in "RT Constraint" routes, and therefore may not be cost-effective in
all scenarios, especially if the number of sources per ASM group is all scenarios, especially if the number of sources per ASM group is
small. This procedure may also result in increased join latency. small. This procedure may also result in increased join latency.
2.9. C-multicast Source/Shared Tree Joins 2.9. C-multicast Source/Shared Tree Joins
[RFC6514] section 11.1.3 has the following procedure for determining Section 11.1.3 of [RFC6514] describes how to determine the IP-
the IP-address-specific RT that is attached to a C-multicast route: address-specific RT(s) that should be attached to a C-multicast
(a) determine the upstream PE, RD, AS, (b) find the proper Inter-AS route. The "upstream PE", "upstream RD", and "source AS" (as defined
or Intra-AS I-PMSI A-D route based on (a), (c) find the next hop of in Section 5 of [RFC6513]) for the NLRI of the C-multicast route are
that A-D route, (d) base the RT on that next hop. first determined. An IP-address-specific RT whose "global
administrator" field carries the IP address of the upstream PE is
then attached to the C-multicast route. This procedure applies as
well to GTM, except that the "upstream PE" is actually an "upstream
PBR".
However, for GTM, in environments where it is known a priori that Section 11.1.3 of [RFC6514] also specifies that a second IP-address
specific RT be attached to the C-multicast route, if the source AS of
the NLRI of that route is different than the AS of the PE originating
the route. The procedure for creating this RT may be summarized as:
(a) determine the upstream PE, upstream RD,and source AS
corresponding to the NLRI of the route;
(b) find the corresponding Inter-AS or Intra-AS I-PMSI A-D route
based on (a);
(c) find the next hop of that A-D route;
(d) place the IP address of that next hop in the global
administrator field of the RT.
However, for GTM, in scenarios where it is known a priori by a PBR
that the next hop of the C-multicast Source/Shared Tree Joins does that the next hop of the C-multicast Source/Shared Tree Joins does
not change during the distribution of those routes, the proper not change during the distribution of those routes, the second RT
procedure for creating the IP-address-specific RT is to just put the (the one based on the next hop of an I-PMSI A-D route) is not needed,
IP Address of the Upstream PBR in the Global Administrator field of and should not be present. In other scenarios, the procedure of
the RT. In other scenarios, the procedure of the previous paragraph section 11.1.3 of [RFC6513] (as modified by this document's sections
(as modified by this document's sections on "RD usage" and "RT on "RD usage" and "RT usage") is applied by the PBRs.
usage") is applied by the PBRs.
3. Differences from other MVPN-like GTM Procedures 3. Differences from other MVPN-like GTM Procedures
The document [RFC7524] also defines a procedure for GTM that is based The document [RFC7524] also defines a procedure for GTM that is based
on the BGP procedures that were developed for MVPN. on the BGP procedures that were developed for MVPN.
However, the GTM procedures of [RFC7524] are different than and are However, the GTM procedures of [RFC7524] are different than and are
NOT interoperable with the procedures defined in this document. NOT interoperable with the procedures defined in this document.
The two sets of procedures can co-exist in the same network, as long The two sets of procedures can co-exist in the same network, as long
skipping to change at page 18, line 17 skipping to change at page 19, line 4
being lost or misrouted. being lost or misrouted.
The procedures of this document require certain BGP routes to carry The procedures of this document require certain BGP routes to carry
IP multicast group addresses. Generally such group addresses are IP multicast group addresses. Generally such group addresses are
only valid within a certain scope. If a BGP route containing a group only valid within a certain scope. If a BGP route containing a group
address is distributed outside the boundaries where the group address address is distributed outside the boundaries where the group address
is meaningful, unauthorized distribution of multicast data flows may is meaningful, unauthorized distribution of multicast data flows may
occur. occur.
6. Additional Contributors 6. Additional Contributors
Jason Schiller
Google
Suite 400
1818 Library Street
Reston, Virginia 20190
United States
Email: jschiller@google.com
Zhenbin Li Zhenbin Li
Huawei Technologies Huawei Technologies
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
Wei Meng Wei Meng
ZTE Corporation ZTE Corporation
skipping to change at page 18, line 49 skipping to change at page 19, line 43
Shunwan Zhuang Shunwan Zhuang
Huawei Technologies Huawei Technologies
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: zhuangshunwan@huawei.com Email: zhuangshunwan@huawei.com
7. Acknowledgments 7. Acknowledgments
The authors and contributors would like to thank Rahul Aggarwal, The authors and contributors would like to thank Rahul Aggarwal,
Huajin Jeng, Hui Ni, Yakov Rekhter, and Samir Saad for their Huajin Jeng, Hui Ni, Yakov Rekhter, and Samir Saad for their ideas
contributions to this work. and comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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>.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
VPNs", RFC 6513, February 2012. BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012. VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>.
[RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure [RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure
Addresses in BGP Updates for Multicast VPN", RFC 6515, Addresses in BGP Updates for Multicast VPN", RFC 6515,
February 2012. DOI 10.17487/RFC6515, February 2012,
<http://www.rfc-editor.org/info/rfc6515>.
8.2. Informative References 8.2. Informative References
[ADD-PATH] [ADD-PATH]
Walton, D., Retana, A., Chen, E., and J. Scudder, Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", internet-draft "Advertisement of Multiple Paths in BGP", internet-draft
draft-ietf-idr-add-paths-10, October 2014. draft-ietf-idr-add-paths-10, October 2014.
[MVPN-extranet] [MVPN-extranet]
Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T. Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T.
skipping to change at page 19, line 46 skipping to change at page 20, line 47
draft draft-ietf-bess-mvpn-extranet-02, May 2015. draft draft-ietf-bess-mvpn-extranet-02, May 2015.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, November 2006. Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
November 2006, <http://www.rfc-editor.org/info/rfc4684>.
[RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol [RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol
Independent Multicast (PIM)", RFC 5294, August 2008. Independent Multicast (PIM)", RFC 5294,
DOI 10.17487/RFC5294, August 2008,
<http://www.rfc-editor.org/info/rfc5294>.
[RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. [RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T.
Yamagata, "Internal BGP as the Provider/Customer Edge Yamagata, "Internal BGP as the Provider/Customer Edge
Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)",
RFC 6368, September 2011. RFC 6368, DOI 10.17487/RFC6368, September 2011,
<http://www.rfc-editor.org/info/rfc6368>.
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
Point-to-Multipoint (P2MP) Segmented Label Switched Paths Point-to-Multipoint (P2MP) Segmented Label Switched Paths
(LSPs)", RFC 7524, May 2015. (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
<http://www.rfc-editor.org/info/rfc7524>.
[RTC_without_RTs] [RTC_without_RTs]
Rosen, E., Ed., Patel, K., Haas, J., and R. Raszuk, "Route Rosen, E., Ed., Patel, K., Haas, J., and R. Raszuk, "Route
Target Constrained Distribution of Routes with no Route Target Constrained Distribution of Routes with no Route
Targets", internet-draft draft-ietf-idr-rtc-no-rt-00, Targets", internet-draft draft-ietf-idr-rtc-no-rt-01, June
January 2015. 2015.
Authors' Addresses Authors' Addresses
Zhaohui Zhang Zhaohui Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
US US
Email: zzhang@juniper.net Email: zzhang@juniper.net
skipping to change at page 21, line 19 skipping to change at line 996
Email: kartsubr@cisco.com Email: kartsubr@cisco.com
Dante J. Pacella Dante J. Pacella
Verizon Verizon
22001 Loudoun County Parkway 22001 Loudoun County Parkway
Ashburn, Virginia 95134 Ashburn, Virginia 95134
US US
Email: dante.j.pacella@verizonbusiness.com Email: dante.j.pacella@verizonbusiness.com
Jason Schiller
Google
Suite 400
1818 Library Street
Reston, Virginia 20190
US
Email: jschiller@google.com
 End of changes. 27 change blocks. 
47 lines changed or deleted 81 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/