< draft-ietf-l3vpn-mldp-vrf-in-band-signaling-01.txt   draft-ietf-l3vpn-mldp-vrf-in-band-signaling-02.txt >
Network Working Group IJ. Wijnands, Ed. Network Working Group IJ. Wijnands, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track P. Hitchen Intended status: Standards Track P. Hitchen
Expires: December 23, 2013 BT Expires: May 23, 2014 BT
N. Leymann N. Leymann
Deutsche Telekom Deutsche Telekom
W. Henderickx W. Henderickx
Alcatel-Lucent Alcatel-Lucent
A. Gulko A. Gulko
Thomson Reuters Thomson Reuters
June 21, 2013 J. Tantsura
Ericsson
November 19, 2013
Multipoint Label Distribution Protocol Multipoint Label Distribution Protocol
In-Band Signaling in a VRF Context In-Band Signaling in a VRF Context
draft-ietf-l3vpn-mldp-vrf-in-band-signaling-01 draft-ietf-l3vpn-mldp-vrf-in-band-signaling-02
Abstract Abstract
Sometimes an IP multicast distribution tree (MDT) traverses both An IP Multicast Distribution Tree (MDT) may traverse both label
MPLS-enabled and non-MPLS-enabled regions of a network. Typically switching (i.e. - Multi-Protocol Label Switching, or MPLS) and non-
the MDT begins and ends in non-MPLS regions, but travels through an label switching regions of a network. Typically the MDT begins and
MPLS region. In such cases, it can be useful to begin building the ends in non-MPLS regions, but travels through an MPLS region. In
MDT as a pure IP MDT, then convert it to an MPLS Multipoint LSP such cases, it can be useful to begin building the MDT as a pure IP
(Label Switched Path) when it enters an MPLS-enabled region, and then MDT, then convert it to an MPLS Multipoint Label Switched Path (MP-
convert it back to a pure IP MDT when it enters a non-MPLS-enabled LSP) when it enters an MPLS-enabled region, and then convert it back
region. Other documents specify the procedures for building such a to a pure IP MDT when it enters a non-MPLS-enabled region. Other
hybrid MDT, using Protocol Independent Multicast (PIM) in the non- documents specify the procedures for building such a hybrid MDT,
MPLS region of the network, and using Multipoint Extensions to Label using Protocol Independent Multicast (PIM) in the non-MPLS region of
Distribution Protocol (mLDP) in the MPLS region. This document the network, and using Multipoint Extensions to Label Distribution
extends those procedures to handle the case where the link connecting Protocol (mLDP) in the MPLS region. This document extends those
the two regions is a "Virtual Routing and Forwarding Table" (VRF) procedures to handle the case where the link connecting the two
link, as defined in the "BGP IP/MPLS VPN" specifications. However, regions is a "Virtual Routing and Forwarding Table" (VRF) link, as
this document is primarily aimed at particular use cases where VRFs defined in the "BGP IP/MPLS VPN" specifications. However, this
are used to support multicast applications other than Multicast VPN. document is primarily aimed at particular use cases where VRFs are
used to support multicast applications other than Multicast VPN.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 23, 2013. This Internet-Draft will expire on May 23, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 4, line 18 skipping to change at page 4, line 18
MPLS-enabled and non-MPLS-enabled regions of a network. Typically MPLS-enabled and non-MPLS-enabled regions of a network. Typically
the MDT begins and ends in non-MPLS regions, but travels through an the MDT begins and ends in non-MPLS regions, but travels through an
MPLS region. In such cases, it can be useful to begin building the MPLS region. In such cases, it can be useful to begin building the
MDT as a pure IP MDT, then convert it to an MPLS Multipoint LSP MDT as a pure IP MDT, then convert it to an MPLS Multipoint LSP
(Label Switched Path) when it enters an MPLS-enabled region, and then (Label Switched Path) when it enters an MPLS-enabled region, and then
convert it back to a pure IP MDT when it enters a non-MPLS-enabled convert it back to a pure IP MDT when it enters a non-MPLS-enabled
region. Other documents specify the procedures for building such a region. Other documents specify the procedures for building such a
hybrid MDT, using Protocol Independent Multicast (PIM) in the non- hybrid MDT, using Protocol Independent Multicast (PIM) in the non-
MPLS region of the network, and using Multipoint Extensions to Label MPLS region of the network, and using Multipoint Extensions to Label
Distribution Protocol (mLDP) in the MPLS region. This document Distribution Protocol (mLDP) in the MPLS region. This document
extends those procedures to handle the case where the link connecting extends the procedures from [RFC6826] to handle the case where the
the two regions is a "Virtual Routing and Forwarding Table" (VRF) link connecting the two regions is a "Virtual Routing and Forwarding
link, as defined in the "BGP IP/MPLS VPN" specifications. However, Table" (VRF) link, as defined in the "BGP IP/MPLS VPN" specifications
this document is primarily aimed at particular use cases where VRFs [RFC6513]. However, this document is primarily aimed at particular
are used to support multicast applications other than Multicast VPN. use cases where VRFs are used to support multicast applications other
than Multicast VPN.
In PIM, a tree is identified by a source address (or in the case of In PIM, a tree is identified by a source address (or in the case of
bidirectional trees [RFC5015], a rendezvous point address or "RPA") bidirectional trees [RFC5015], a rendezvous point address or "RPA")
and a group address. The tree is built from the leaves up, by and a group address. The tree is built from the leaves up, by
sending PIM control messages in the direction of the source address sending PIM control messages in the direction of the source address
or the RPA. In mLDP, a tree is identified by a root address and an or the RPA. In mLDP, a tree is identified by a root address and an
"opaque value", and is built by sending mLDP control messages in the "opaque value", and is built by sending mLDP control messages in the
direction of the root. The procedures of direction of the root. The procedures of [RFC6826] explain how to
[I-D.ietf-mpls-mldp-in-band-signaling] explain how to convert a PIM convert a PIM <source address or RPA, group address> pair into an
<source address or RPA, group address> pair into an mLDP <root node, mLDP <root node, opaque value> pair and how to convert the mLDP <root
opaque value> pair;, and how to convert the mLDP <root node, opaque node, opaque value> pair back into the original PIM <source address
value> pair back into the original PIM <source address or RPA, group or RPA, group address> pair.
address> pair.
However, those procedures assume that the routers doing the PIM/mLDP However, the procedures in [RFC6826] assume that the routers doing
conversion have routes to the source address or RPA in their global the PIM/mLDP conversion have routes to the source address or RPA in
routing tables. Thus the procedures cannot be applied exactly as their global routing tables. Thus the procedures cannot be applied
specified when the interfaces connecting the non-MPLS-enabled region exactly as specified when the interfaces connecting the non-MPLS-
to the MPLS-enabled region are interfaces that belong to a VRF as enabled region to the MPLS-enabled region are interfaces that belong
described in [RFC4364]. This specification extends the procedures of to a VRF as described in [RFC4364]. This specification extends the
[I-D.ietf-mpls-mldp-in-band-signaling] so that they may be applied in procedures of [RFC6826] so that they may be applied in the VRF
the VRF context. context.
As in [I-D.ietf-mpls-mldp-in-band-signaling], the scope of this As in [RFC6826], the scope of this document is limited to the case
document is limited to the case where the multicast content is where the multicast content is distributed in the non-MPLS-enabled
distributed in the non-MPLS-enabled regions via PIM-created Source- regions via PIM-created Source-Specific or Bidirectional trees.
Specific or Bidirectional trees. Bidirectional trees are always Bidirectional trees are always mapped onto Multipoint-to-Multipoint
mapped onto Multipoint-to-Multipoint LSPs, and source-specific trees LSPs, and source-specific trees are always mapped onto Point-to-
are always mapped onto Point-to-Multipoint LSPs. Multipoint LSPs.
Note that the procedures described herein do not support non- Note that the procedures described herein do not support non-
bidirectional PIM ASM groups, do not support the use of multicast bidirectional PIM ASM groups, do not support the use of multicast
trees other than mLDP multipoint LSPs in the core, and do not provide trees other than mLDP multipoint LSPs in the core, and do not provide
the capability to aggregate multiple PIM trees onto a single the capability to aggregate multiple PIM trees onto a single
multipoint LSP. If any of those features are needed, they can be multipoint LSP. If any of those features are needed, they can be
provided by the procedures of [RFC6513] and [RFC6514]. However, provided by the procedures of [RFC6513] and [RFC6514]. However,
there are cases where multicast services are offered through VRF there are cases where multicast services are offered through
interfaces, and where mLDP is used in the core, but where aggregation interfaces associated with a VRF, and where mLDP is used in the core,
is not desired. For example, some service providers offer multicast but where aggregation is not desired. For example, some service
content to their customers, but have chosen to use VRFs to isolate providers offer multicast content to their customers, but have chosen
the various customers and services. This is a simpler scenario that to use VRFs to isolate the various customers and services. This is a
one in which the customers provide their own multicast content, out simpler scenario than one in which the customers provide their own
of the control of the service provider, and can be handled with a multicast content, out of the control of the service provider, and
simpler solution. Also, when PIM trees are mapped one-to-one to can be handled with a simpler solution. Also, when PIM trees are
multipoint LSPs, it is helpful for troubleshooting purposes to have mapped one-to-one to multipoint LSPs, it is helpful for
the PIM source/group addresses encoded into the mLDP FEC element. troubleshooting purposes to have the PIM source/group addresses
encoded into the mLDP FEC element.
In order to use the mLDP in-band signaling procedures for a In order to use the mLDP in-band signaling procedures for a
particular group address in the context of a particular set of VRFs, particular group address in the context of a particular set of VRFs,
those VRFs MUST be configured with a range of multicast group those VRFs MUST be configured with a range of multicast group
addresses for which mLDP in-band signaling is to be enabled. This addresses for which mLDP in-band signaling is to be enabled. This
configuration is per VRF ("Virtual Routing and Forwarding table", configuration is per VRF ("Virtual Routing and Forwarding table",
defined in [RFC4364]). For those groups, and those groups only, the defined in [RFC4364]). For those groups, and those groups only, the
procedures of this document are used. For other groups the general procedures of this document are used. For other groups the general
purpose Multicast VPN procedures MAY be used, although it is more purpose Multicast VPN procedures MAY be used, although it is more
likely this VRF is dedicated to mLDP in-band signaling procedures and likely this VRF is dedicated to mLDP in-band signaling procedures and
skipping to change at page 5, line 47 skipping to change at page 5, line 48
1.1. Conventions used in this document 1.1. Conventions used in this document
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].
1.2. Terminology 1.2. Terminology
IP multicast tree : An IP multicast distribution tree identified by IP multicast tree : An IP multicast distribution tree identified by
an source IP address and/or IP multicast destination address, also a source IP address and/or IP multicast destination address, also
referred to as (S,G) and (*,G). referred to as (S,G) and (*,G).
mLDP : Multicast LDP. mLDP : Multicast LDP.
In-band signaling : Using the opaque value of a mLDP FEC element to In-band signaling : Using the opaque value of a mLDP FEC element to
encode the (S,G) or (*,G) identifying a particular IP multicast encode the (S,G) or (*,G) identifying a particular IP multicast
tree. tree.
P2MP LSP: An LSP that has one Ingress LSR and one or more Egress P2MP LSP: An LSP that has one Ingress LSR and one or more Egress
LSRs (see [RFC6388]). LSRs (see [RFC6388]).
skipping to change at page 6, line 26 skipping to change at page 6, line 26
MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.
Ingress LSR: Source of a P2MP LSP, also referred to as root node. Ingress LSR: Source of a P2MP LSP, also referred to as root node.
VRF: Virtual Routing and Forwarding table. VRF: Virtual Routing and Forwarding table.
2. VRF In-band signaling for MP LSPs 2. VRF In-band signaling for MP LSPs
Suppose that a PE router, PE1, receives a PIM Join(S,G) message over Suppose that a PE router, PE1, receives a PIM Join(S,G) message over
one of its VRF interfaces. Following the procedure of section 5.1 of one of its interfaces that is associated with a VRF. Following the
[RFC6513], PE1 determines the "upstream RD", the "upstream PE", and procedure of section 5.1 of [RFC6513], PE1 determines the "upstream
the "upstream multicast hop" (UMH) for the source address S. Please RD", the "upstream PE", and the "upstream multicast hop" (UMH) for
note that sections 5.1.1 and 5.1.2 of [RFC6513] are applicable. the source address S.
In order to transport the multicast tree via a MP LSP using VRF in- In order to transport the multicast tree via a MP LSP using VRF in-
band signaling, an mLDP Label Mapping Message is sent by PE1. This band signaling, an mLDP Label Mapping Message is sent by PE1. This
message will contain either a P2MP FEC or an MP2MP FEC (see message will contain either a P2MP FEC or an MP2MP FEC (see
[RFC6388], depending upon whether the PIM tree being transported is a [RFC6388]), depending upon whether the PIM tree being transported is
source-specific tree, or a bidirectional tree, respectively. The FEC a source-specific tree, or a bidirectional tree, respectively. The
contains a "root" and an "opaque value". FEC contains a "root" and an "opaque value".
If the UMH and the upstream PE have the same IP address (i.e., the If the UMH and the upstream PE have the same IP address (i.e., the
Upstream PE is the UMH), then the root of the Multipoint FEC is set Upstream PE is the UMH), then the root of the Multipoint FEC is set
to the IP address of the Upstream PE. If, in the context of this to the IP address of the Upstream PE. If, in the context of this
VPN, (S,G) refers to a source-specific MDT, then the values of S, G, VPN, (S,G) refers to a source-specific MDT, then the values of S, G,
and the upstream RD are encoded into the opaque value. If, in the and the upstream RD are encoded into the opaque value. If, in the
context of this VPN, G is a bidirectional group address, then S is context of this VPN, G is a bidirectional group address, then S is
replaced with the value of the RPA associated with G. The coding replaced with the value of the RPA associated with G.
details are specified in Section 3. Conceptually, the Multipoint FEC
can be thought of as an ordered pair: <root=Upstream-PE, The encoding details are specified in Section 3. Conceptually, the
opaque_value=<S or RPA ,G ,Upstream-RD>. The mLDP Label Mapping Multipoint FEC can be thought of as an ordered pair:
Message is then sent by PE1 on its LDP session to the "next hop" on {root=<Upstream-PE>; opaque_value=<S or RPA ,G ,Upstream-RD>}. The
its path to the upstream PE. The "next hop" is usually the IGP next mLDP Label Mapping Message is then sent by PE1 on its LDP session to
hop, but see [I-D.ietf-mpls-targeted-mldp] for cases in which the the "next hop" on the message's path to the upstream PE. The "next
next hop is not the IGP next hop. hop" is usually the directly connected next hop, but see
[I-D.ietf-mpls-targeted-mldp] for cases in which the next hop is not
directly connected.
If the UMH and the upstream PE do not have the same IP address, the If the UMH and the upstream PE do not have the same IP address, the
procedures of section 2 of [RFC6512] should be applied. The root procedures of section 2 of [RFC6512] should be applied. The root
node of the multipoint FEC is set to the UMH. The recursive opaque node of the multipoint FEC is set to the UMH. The recursive opaque
value is then set as follows: the root node is set to the upstream value is then set as follows: the root node is set to the upstream
PE, and the opaque value is set to the multipoint FEC described in PE, and the opaque value is set to the multipoint FEC described in
the previous paragraph. That is, the multipoint FEC can be thought the previous paragraph. That is, the multipoint FEC can be thought
of as the following recursive ordered pair: <root=UMH, of as the following recursive ordered pair: {root=<UMH>;
opaque_value=<root=Upstream-PE, opaque_value =<S or RPA, G, opaque_value=<root=Upstream-PE, opaque_value =<S or RPA, G,
Upstream-RD>>. Upstream-RD>>}.
The encoding of the multipoint FEC also specifies the "type" of PIM The encoding of the multipoint FEC also specifies the "type" of PIM
MDT being spliced onto the multipoint LSP. Four types of MDT are MDT being spliced onto the multipoint LSP. Four types of MDT are
defined: IPv4 source-specific tree, IPv6 source-specific tree, IPv4 defined in [RFC6826]: IPv4 source-specific tree, IPv6 source-specific
bidirectional tree, and IPv6 bidirectional tree. tree, IPv4 bidirectional tree, and IPv6 bidirectional tree.
When a PE router receives an mLDP message with a P2MP or MP2MP FEC, When a PE router receives an mLDP message with a P2MP or MP2MP FEC,
where the PE router itself is the root node, and the opaque value is where the PE router itself is the root node, and the opaque value is
one of the types defined in Section 3, then it uses the RD encoded in one of the types defined in Section 3, then it uses the RD encoded in
the opaque value field to determine the VRF context. (This RD will the opaque value field to determine the VRF context. (This RD will
be associated with one of the PEs VRFs.) Then, in the context of be associated with one of the PEs VRFs.) Then, in the context of
that VRF, the PE follows the procedure specified in section 2 of that VRF, the PE follows the procedure specified in section 2 of
[I-D.ietf-mpls-mldp-in-band-signaling]. [RFC6826].
3. Encoding the Opaque Value of an LDP MP FEC 3. Encoding the Opaque Value of an LDP MP FEC
This section documents the different transit opaque encodings. This section documents the different transit opaque encodings.
3.1. Transit VPNv4 Source TLV 3.1. Transit VPNv4 Source TLV
This opaque value type is used when transporting a source-specific This opaque value type is used when transporting a source-specific
mode multicast tree whose source and group addresses are IPv4 mode multicast tree whose source and group addresses are IPv4
addresses. addresses.
skipping to change at page 11, line 17 skipping to change at page 11, line 17
RD: Route Distinguisher, 8 octets. RD: Route Distinguisher, 8 octets.
4. Security Considerations 4. Security Considerations
The same security considerations apply as for the base LDP The same security considerations apply as for the base LDP
specification, described in [RFC5036], and the base mLDP specification, described in [RFC5036], and the base mLDP
specification, described in [RFC6388] specification, described in [RFC6388]
5. IANA considerations 5. IANA considerations
[RFC6388] defines a registry for "The LDP MP Opaque Value Element [RFC6388] defines a registry for "The LDP MP Opaque Element Basic
Basic Type". This document requires the assignment of four new code Type". This document requires the assignment of four new code points
points in this registry: in this registry:
Transit VPNv4 Source TLV type - requested 250 Transit VPNv4 Source TLV type - requested 250
Transit VPNv6 Source TLV type - requested 251 Transit VPNv6 Source TLV type - requested 251
Transit VPNv4 Bidir TLV type - requested 9 Transit VPNv4 Bidir TLV type - requested TBD-1
Transit VPNv6 Bidir TLV type - requested 10 Transit VPNv6 Bidir TLV type - requested TBD-2
6. Acknowledgments 6. Acknowledgments
Thanks to Eric Rosen, Andy Green and Yakov Rekhter for their comments Thanks to Eric Rosen, Andy Green, Yakov Rekhter and Eric Gray for
on the draft. their comments on the draft.
7. References 7. References
7.1. Normative References 7.1. Normative References
[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, February 2006.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
skipping to change at page 12, line 17 skipping to change at page 12, line 17
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to- "Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011. Paths", RFC 6388, November 2011.
[RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, [RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann,
"Using Multipoint LDP When the Backbone Has No Route to "Using Multipoint LDP When the Backbone Has No Route to
the Root", RFC 6512, February 2012. the Root", RFC 6512, February 2012.
[I-D.ietf-mpls-mldp-in-band-signaling] [RFC6826] Wijnands, IJ., Eckert, T., Leymann, N., and M. Napierala,
Wijnands, I., Eckert, T., Leymann, N., and M. Napierala, "Multipoint LDP In-Band Signaling for Point-to-Multipoint
"Multipoint LDP in-band signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths",
and Multipoint- to-Multipoint Label Switched Paths", RFC 6826, January 2013.
draft-ietf-mpls-mldp-in-band-signaling-06 (work in
progress), June 2012.
7.2. Informative References 7.2. Informative References
[I-D.ietf-mpls-targeted-mldp] [I-D.ietf-mpls-targeted-mldp]
Napierala, M. and E. Rosen, "Using LDP Multipoint Napierala, M. and E. Rosen, "Using LDP Multipoint
Extensions on Targeted LDP Sessions", Extensions on Targeted LDP Sessions",
draft-ietf-mpls-targeted-mldp-00 (work in progress), draft-ietf-mpls-targeted-mldp-01 (work in progress),
August 2012. January 2013.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", RFC 6513, February 2012. VPNs", RFC 6513, February 2012.
[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, February 2012.
Authors' Addresses Authors' Addresses
skipping to change at line 493 skipping to change at page 13, line 35
Email: wim.henderickx@alcatel-lucent.com Email: wim.henderickx@alcatel-lucent.com
Arkadiy Gulko Arkadiy Gulko
Thomson Reuters Thomson Reuters
195 Broadway 195 Broadway
New York NY 10007 New York NY 10007
USA USA
Email: arkadiy.gulko@thomsonreuters.com Email: arkadiy.gulko@thomsonreuters.com
Jeff Tantsura
Ericsson
300 Holger Way
San Jose, california 95134
usa
Email: jeff.tantsura@ericsson.com
 End of changes. 25 change blocks. 
91 lines changed or deleted 95 lines changed or added

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