draft-ietf-l2vpn-vpms-frmwk-requirements-02.txt   draft-ietf-l2vpn-vpms-frmwk-requirements-03.txt 
Network Working Group Y. Kamite Network Working Group Y. Kamite
Internet-Draft NTT Communications Internet-Draft NTT Communications
Intended status: Informational F. Jounay Intended status: Informational F. Jounay
Expires: April 29, 2010 France Telecom Expires: January 13, 2011 France Telecom
B. Niven-Jenkins B. Niven-Jenkins
BT Velocix
D. Brungard D. Brungard
AT&T AT&T
L. Jin L. Jin
Nokia Siemens Networks ZTE
Oct 26, 2009 July 12, 2010
Framework and Requirements for Virtual Private Multicast Service (VPMS) Framework and Requirements for Virtual Private Multicast Service (VPMS)
draft-ietf-l2vpn-vpms-frmwk-requirements-02.txt draft-ietf-l2vpn-vpms-frmwk-requirements-03.txt
Abstract
This document provides a framework and service level requirements for
Virtual Private Multicast Service (VPMS). VPMS is defined as a Layer
2 VPN service that provides point-to-multipoint connectivity for a
variety of Layer 2 link layers across an IP or MPLS-enabled PSN.
This document outlines architectural service models of VPMS and
states generic and high level requirements. This is intended to aid
in developing protocols and mechanisms to support VPMS.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 13, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document provides a framework and service level requirements for described in the Simplified BSD License.
Virtual Private Multicast Service (VPMS). VPMS is defined as a Layer
2 VPN service that provides point-to-multipoint connectivity for a
variety of Layer 2 link layers across an IP or MPLS-enabled PSN.
This document outlines architectural service models of VPMS and
states generic and high level requirements. This is intended to aid
in developing protocols and mechanisms to support VPMS.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope of This Document . . . . . . . . . . . . . . . . . . 4 1.2. Scope of This Document . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5 2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
skipping to change at page 6, line 20 skipping to change at page 6, line 20
4.1. Ethernet Use Case 4.1. Ethernet Use Case
4.1.1. Ethernet-based multicast stream 4.1.1. Ethernet-based multicast stream
For multicast traffic delivery, there is a requirement to deliver a For multicast traffic delivery, there is a requirement to deliver a
unidirectional P2MP service in addition to the existing P2P service. unidirectional P2MP service in addition to the existing P2P service.
The demand is growing to provide private (P2MP native Ethernet) The demand is growing to provide private (P2MP native Ethernet)
services, for various applications such as IP- based delivery of TV services, for various applications such as IP- based delivery of TV
broadcasting, content delivery networks, etc. Moreover, many digital broadcasting, content delivery networks, etc. Moreover, many digital
audio/video devices (e.g., MPEG-TS, HD-SDI) that supports Ethernet audio/video devices (e.g., MPEG-TS, HD-SDI) that support Ethernet
interfaces are becoming available, which will make Ethernet P2MP interfaces are becoming available, which will make Ethernet P2MP
service more common. Also there are some applications that naturally service more common. Also there are some applications that naturally
suited to static transport of VPMS. For example, MPEG-TS/IP/ suited to static transport of VPMS. For example, MPEG-TS/IP/Ethernet
Ethernet in DVB-H is typically static broadcast without any signaling in DVB-H is typically static broadcast without any signaling in the
in the upstream direction. VPMS could be a possible solution to upstream direction. VPMS could be a possible solution to provide
provide these kinds of networking connectivity over PSNs. these kinds of networking connectivity over PSNs.
Currently VPLS [RFC4761][RFC4762] is able to give P2MP-type Currently VPLS [RFC4761][RFC4762] is able to give P2MP-type
replication for Ethernet traffic. Native VPLS already supports this replication for Ethernet traffic. Native VPLS already supports this
capability via a full mesh of PWs, and an extension to optimize capability via a full mesh of PWs, and an extension to optimize
replication is also proposed [I-D.ietf-l2vpn-vpls-mcast] as an replication is also proposed [I-D.ietf-l2vpn-vpls-mcast] as an
additional feature. However, VPLS by nature requires MAC-based additional feature. However, VPLS by nature requires MAC-based
learning and forwarding, which might not be needed in some cases by learning and forwarding, which might not be needed in some cases by
particular users. Generally, video distribution applications use particular users. Generally, video distribution applications use
unidirectional P2MP traffic, but may not always require any added unidirectional P2MP traffic, but may not always require any added
complexity of MAC address management. In addition, VPLS is a service complexity of MAC address management. In addition, VPLS is a service
skipping to change at page 7, line 11 skipping to change at page 7, line 11
MAC addresses are not used for forwarding, which is significantly MAC addresses are not used for forwarding, which is significantly
different from VPLS. If MAC-based forwarding is preferred (i.e., different from VPLS. If MAC-based forwarding is preferred (i.e.,
multicast/unicast differentiation of MAC address), VPLS should be multicast/unicast differentiation of MAC address), VPLS should be
chosen rather than VPMS. chosen rather than VPMS.
4.1.2. Ethernet-based time/frequency synchronization 4.1.2. Ethernet-based time/frequency synchronization
Nowadays there exist several solutions to provide synchronization for Nowadays there exist several solutions to provide synchronization for
time and/or frequency reference by the packet-based technology of time and/or frequency reference by the packet-based technology of
Ethernet. For example, PTPv2 (Precision Time Protocol version 2) is Ethernet. For example, PTPv2 (Precision Time Protocol version 2) is
a time-transfer protocol defined in the IEEEE1588-2008 standard. It a time-transfer protocol defined in the IEEE 1588-2008 standard. It
provides precise synchronization of packet-based networks (e.g., provides precise synchronization of packet-based networks (e.g.,
Ethernet). It adopts two-way time transfer approach for Ethernet). It adopts two-way time transfer approach for
synchronization. Time transfer protocol may be operated in multicast synchronization. Time transfer protocol may be operated in multicast
or unicast mode in both directions, and it is mapped over the or unicast mode in both directions, and it is mapped over the
Ethernet/IP/UDP protocol stack. Ethernet/IP/UDP protocol stack.
Moreover, PTPv2 telecom profile is now discussed in ITU-T that Moreover, PTPv2 telecom profile is now discussed in ITU-T that
defines a set of capabilities and extensions required to support defines a set of capabilities and extensions required to support
telecommunication applications. It aims at providing frequency telecommunication applications. It aims at providing frequency
distribution with higher level of accuracy. It allows unicast mode distribution with higher level of accuracy. It allows unicast mode
skipping to change at page 9, line 46 skipping to change at page 9, line 46
A CE which is locally connected to a root AC is called a root A CE which is locally connected to a root AC is called a root
(sender) CE. Also a CE which is locally connected to a leaf AC is (sender) CE. Also a CE which is locally connected to a leaf AC is
called a leaf (receiver) CE. However, such CEs's roles will not be called a leaf (receiver) CE. However, such CEs's roles will not be
managed directly in VPMS because the configured AC's role (root or managed directly in VPMS because the configured AC's role (root or
leaf) will automatically determine them. leaf) will automatically determine them.
Similarly, a PE which locally accommodates a root AC is called a root Similarly, a PE which locally accommodates a root AC is called a root
(sender) PE. A PE which locally accommodates a leaf AC is called a (sender) PE. A PE which locally accommodates a leaf AC is called a
leaf (receiver) PE. leaf (receiver) PE.
Root AC and leaf ACs are typically located at separate PEs as shown
in Figure 1, but it is also allowed that a single PE locally has both
a root AC and one or more leaf ACs.
Basically there is a one-to-one mapping between an attachment circuit Basically there is a one-to-one mapping between an attachment circuit
and a VPMS instance. For example, all traffic from CE1 to PE1 and a VPMS instance. For example, all traffic from CE1 to PE1
(through AC1) is mapped to VPMS A (to CE2 and CE5). (through AC1) is mapped to VPMS A (to CE2 and CE5).
In a VPMS, P2MP tree-shaped reachability is given from a single root In a VPMS, P2MP tree-shaped reachability is given from a single root
AC to several leaf ACs. This will be named a "P2MP connection" in AC to several leaf ACs. This will be named a "P2MP connection" in
this VPMS framework. P2MP connection is a logical entity between PE/ this VPMS framework. P2MP connection is a logical entity between PE/
ACs in a given VPMS instance that transfers unidirectional traffic ACs in a given VPMS instance that transfers unidirectional traffic
transparently from one local ingress AC to one or more remote egress transparently from one local ingress AC to one or more remote egress
ACs. ACs.
skipping to change at page 10, line 38 skipping to change at page 10, line 42
6. Customer Requirements 6. Customer Requirements
6.1. Service Topology 6.1. Service Topology
6.1.1. Point-to-Multipoint Traffic Support 6.1.1. Point-to-Multipoint Traffic Support
A solution MUST support unidirectional point-to-multipoint traffic A solution MUST support unidirectional point-to-multipoint traffic
from a sender CE to multiple receiver CEs. A root CE can send from a sender CE to multiple receiver CEs. A root CE can send
traffic to one or more leaf CEs. Leaf CEs include not only the CEs traffic to one or more leaf CEs. Leaf CEs include not only the CEs
which are located at remote sites, but also the local CEs which are which are located at remote sites, but also the local CEs which are
connected to the same root PE. If there is only one receiver in the connected to the same root PE (i.e., when a root AC and some of leaf
instance, it is considered equivalent to unidirectional point-to- ACs are co-located). If there is only one receiver in the instance,
point traffic. it is considered equivalent to unidirectional point-to-point traffic.
6.1.2. Reverse Traffic Support 6.1.2. Reverse Traffic Support
There are cases where a reverse traffic flow is needed. A root CE There are cases where a reverse traffic flow is needed. A root CE
may need to receive traffic from leaf CEs. There are some usage may need to receive traffic from leaf CEs. There are some usage
scenarios for this, such as stream monitoring through a loopback scenarios for this, such as stream monitoring through a loopback
mechanism, control channels which need feedback communication etc. A mechanism, control channels which need feedback communication etc. A
possible way to accomplish this is to provide different VPMS possible way to accomplish this is to provide different VPMS
instances for reverse traffic, i.e. a root CE is a receiver of instances for reverse traffic, i.e. a root CE is a receiver of
another VPMS instance. However, provisioning different VPNs for a another VPMS instance. However, provisioning different VPNs for a
particular customer would make its management task more complex. It particular customer would make its management task more complex. It
is desired to have an alternative solution for supporting reverse is desired to have an alternative solution for supporting reverse
traffic flow. This section provides additional requirements for this traffic flow. This section provides additional requirements for this
optional capability. optional capability.
A VPMS solution MAY support reverse traffic from a leaf AC to a root Therefore, a VPMS solution MAY support reverse traffic from a leaf AC
AC. Each reverse path is basically given in a P2P (unicast) manner. to a root AC. Each reverse path is basically given in a P2P
In other words, each leaf of the P2MP tree can individually send back (unicast) manner. In other words, each leaf of the P2MP tree can
traffic to the root. For this purpose a VPMS instance MAY have more individually send back traffic to the root. For this purpose a VPMS
than one reverse P2P connections as network entity; However, such instance MAY have more than one reverse P2P connections as network
network entities MUST have a common indetifier that enables entity; However, such network entities MUST have a common indetifier
themselves to be managed together in the same VPN. Thus any PWs used that enables themselves to be managed together in the same VPN. Thus
for such connections are expected to be assigned a common VPMS any PWs used for such connections are expected to be assigned a
instance ID (i.e., VPN ID). common VPMS instance ID (i.e., VPN ID).
Note, a VPMS does not assume any-to-any multipoint reachability. Note, a VPMS does not assume any-to-any multipoint reachability.
Therefore, in principle, every leaf AC does not exchange traffic Therefore, in principle, every leaf AC does not need to exchange
directly with other leaf ACs even if reverse traffic is supported. traffic directly with other leaf ACs even if reverse traffic is
supported.
Figure 3 illustrates this kind of scenario, where CE1 is configured Figure 3 illustrates this kind of scenario, where CE1 is configured
as a sender in VPMS A. AC1 is a root AC, and AC2/AC3/AC4 are leaf as a sender in VPMS A. AC1 is a root AC, and AC2/AC3/AC4 are leaf
ACs. P2MP connection is given for forward traffic. Unidirectional ACs. P2MP connection is given for traffic in the forward direction.
P2P connection is also provided for reverse traffic from AC4 to AC1. Unidirectional P2P connection is also provided for traffic in the
Other reverse P2P connections can be provided similarly. (from AC2 to reverse direction, from AC4 to AC1. Other reverse P2P connections
AC1 / from AC3 to AC1). can be provided similarly. (from AC2 to AC1 / from AC3 to AC1).
In this case, PEs need to deal with two types of traffic, locally- In this case, PEs need to deal with two types of traffic, locally-
attached CE's sending (Tx) and receiving (Rx) flows. In Figure 3, attached CE's sending (Tx) and receiving (Rx) flows. In Figure 3,
they are both passing through the same physical PE-CE link (AC1 and they are both passing through the same physical PE-CE link (AC1 and
AC4 respectively). But it is an implementation matter if Tx and Rx AC4 respectively). But it is an implementation matter if Tx and Rx
traffic are conveyed on the same physical link or separate links. It traffic are conveyed on the same physical link or separate links. It
is also possible that a root PE multiplexes two ore more reverse is also possible that a root PE multiplexes two ore more reverse
traffic from different leaves and transmits it to an upstream CE over traffic from different leaves and transmits it to an upstream CE over
the same local physical link. the same local physical link.
skipping to change at page 15, line 47 skipping to change at page 15, line 47
AC3| |AC4 AC3| |AC4
v v v v
+-----+ +-----+ +-----+ +-----+
| CE3 | | CE4 | | CE3 | | CE4 |
+-----+ +-----+ +-----+ +-----+
VPMS A VPMS A VPMS A VPMS A
Receiver Receiver Receiver Receiver
Figure 4: Multiple P2MP connections in Dual-homed Sender Figure 4: Multiple P2MP connections in Dual-homed Sender
Note, if the solution supports dual-homed sender scenario to provide Note, if the solution supports dual-homed sender scenario that
multiple root ACs like, it is expected that such a mechanism can also provides multiple root ACs, it is expected that such a mechanism can
be used in multi-source scenrio. For example, suppose in TV also be used in a multi-source scenrio. For example, suppose in TV
provisioning scenario, a leaf (receiver) CE has the fixed one provisioning scenario, a leaf (receiver) CE has the fixed one
interface to the leaf PE, and the CE needs to receive many TV channel interface to the leaf PE, and the CE needs to receive many TV channel
traffic from two video servers (the two servers provide different TV traffic from two video servers (the two servers provide different TV
channels). The two video servers are in different location. In this channels). The two video servers are in different location. In this
case, there need two root ACs and the same number of P2MP case, there need two root ACs and the same number of P2MP
connections, which is similar to dual-homed sender case. If the root connections, which is similar to dual-homed sender case. If the root
CE shown in Figure 4 is given physically separated, such a topology CE shown in Figure 4 is given physically separated, such a topology
is equivalent to this multi-source scenario. is equivalent to this multi-source scenario.
6.4.2. Single/Dual Traffic Support in Dual-homed Access 6.4.2. Single/Dual Traffic Support in Dual-homed Access
When dual-homed access to root PEs is provided, a solution MAY allow When dual-homed access to root PEs is provided, a solution MAY allow
a sender CE to transmit just a single copy of the traffic to either a sender CE to transmit just a single copy of the traffic to either
one of the two root (ingress) PEs or to transmit a copy of the one of the two root (ingress) PEs or to transmit a copy of the
traffic to both the PEs simultaneously. The latter scenario consumes traffic to both the PEs simultaneously. The latter scenario consumes
more resource of CE-PE link than the single traffic scenario, but it more resource of CE-PE link than the single traffic scenario, but it
is usually applicable when a source device has only a simple is usually applicable when a source device has only a simple
forwarding capability without any switchover functionality. In the forwarding capability without any switchover functionality. In such
dual traffic case, the backup root (ingress) PE SHOULD be able to a dual traffic case, the backup root (ingress) PE SHOULD be able to
filter the incoming unnecessary traffic while the other root PE is filter the incoming unnecessary traffic while the other root PE is
active if it is needed by SP. In either case, single traffic or dual active if it is needed by SP. In either case, single traffic or dual
traffic, the switchover mechanism between root (ingress) PEs will be traffic, the switchover mechanism between root (ingress) PEs will be
necessary to handle traffic appropriately in case of failure. necessary to handle traffic appropriately in case of failure.
In the case of dual-homed access to leaf PEs, a solution MAY allow a In the case of dual-homed access to leaf PEs, a solution MAY allow a
receiver CE to receive a single copy of the traffic from either one receiver CE to receive a single copy of the traffic from either one
of the two leaf (egress) PEs, or receive a copy of the traffic from of the two leaf (egress) PEs, or receive a copy of the traffic from
both PEs simultaneously. The dual traffic approach is applicable if both PEs simultaneously. The dual traffic approach is applicable if
CE has fast switchover capability as a receiver by selecting either CE has fast switchover capability as a receiver by selecting either
skipping to change at page 19, line 25 skipping to change at page 19, line 25
instance and this AC is configured as leaf. This information will be instance and this AC is configured as leaf. This information will be
automatically discovered by the other existing remote PEs (i.e., automatically discovered by the other existing remote PEs (i.e.,
ingress and egress PEs in the same VPMS instance). Once the ingress ingress and egress PEs in the same VPMS instance). Once the ingress
PE1 discovers this new PE/AC, it can automatically add AC4 as the new PE1 discovers this new PE/AC, it can automatically add AC4 as the new
leaf of P2MP connection topology according to P2MP PW signaling leaf of P2MP connection topology according to P2MP PW signaling
mechanism. The ingress PE1 will graft a new leaf (PE4) to the mechanism. The ingress PE1 will graft a new leaf (PE4) to the
already existing P2MP connection which is now created from AC1 to already existing P2MP connection which is now created from AC1 to
AC2/AC3/AC4. This operation does not require any new configuration AC2/AC3/AC4. This operation does not require any new configuration
at the existing PEs. at the existing PEs.
Another example is about adding new root PE: suppose there are one Another example is about adding a new root PE: suppose there are one
root PE (PE1/AC1) and three leaf PEs (PE2/AC2, PE3/AC3 and PE4/AC4). root PE (PE1/AC1) and three leaf PEs (PE2/AC2, PE3/AC3 and PE4/AC4).
There is an existing P2MP connection from AC1 to AC2/AC3/AC4. Now There is an existing P2MP connection from AC1 to AC2/AC3/AC4. Now
the operator adds a new root PE/AC (PE5/AC5) for some reasons (e.g., the operator adds a new root PE/AC (PE5/AC5) for some reasons (e.g.,
multiple source sites, dual-homed access, root PE redundancy etc.). multiple source sites, dual-homed access, root PE redundancy etc.).
Then, auto-discovery mechanism advertises this information to all Then, auto-discovery mechanism advertises this information to all
other members PE1/PE2/PE3/PE4, and a new P2MP connection from AC5 to other members PE1/PE2/PE3/PE4, and a new P2MP connection from AC5 to
AC2/AC3/AC4 is created by PW signaling. AC2/AC3/AC4 is created by PW signaling.
Note that VPMS instance is created when one root PE and at least one Note that VPMS instance is created when one root AC and at least one
leaf PE are added. In principle VPMS requires such minimum leaf AC are added. In principle VPMS requires such minimum
provisioning. Hence in dual-homing case of sender, only backup root provisioning. Hence in dual-homing case of sender, only backup root
PE can be dynamically added/deleted to/from VPMS without destroying PE can be dynamically added/deleted to/from VPMS without destroying
the VPN. the VPN.
7.4. Activation and Deactivation 7.4. Activation and Deactivation
A solution SHOULD provide a way to activate/deactivate the A solution SHOULD provide a way to activate/deactivate the
administrative status of each AC. After initial provisioning, a SP administrative status of each AC. After initial provisioning, an SP
might change connectivity configuration between particular CEs inside might change connectivity configuration between particular CEs inside
a single VPMS instance for operational reasons. This feature will be a single VPMS instance for operational reasons. This feature will be
beneficial to help such a scenario. beneficial to help such a scenario.
For example, in Figure 5, AC1, AC3, AC4 and AC5 are initially For example, in Figure 5, AC1, AC3, AC4 and AC5 are initially
provisioned for VPMS A. AC2 is not provisioned for any VPMSes. In provisioned for VPMS A. AC2 is not provisioned for any VPMSes. In
VPMS A, CE1 is a sender and CE3, CE4 and CE5 are receivers. Traffic VPMS A, CE1 is a sender and CE3, CE4 and CE5 are receivers. Traffic
will usually flow from CE1 to all receivers, CE3, CE4 and CE5. will usually flow from CE1 to all receivers, CE3, CE4 and CE5.
However, for maintenance operation, application's request (e.g., However, for maintenance operation, application's request (e.g.,
skipping to change at page 25, line 16 skipping to change at page 25, line 16
[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.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, March 2005. Private Network (VPN) Terminology", RFC 4026, March 2005.
11.2. Informative References 11.2. Informative References
[I-D.ietf-l2vpn-vpls-mcast] [I-D.ietf-l2vpn-vpls-mcast]
Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter, Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter,
"Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-05 (work "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-06 (work
in progress), July 2009. in progress), March 2010.
[I-D.ietf-pwe3-p2mp-pw-requirements] [I-D.ietf-pwe3-p2mp-pw-requirements]
JOUNAY, F., Niger, P., Kamite, Y., DeLord, S., and L. Heron, G., Wang, L., Aggarwal, R., Vigoureux, M., Bocci,
Martini, "Requirements for Point-to-Multipoint M., Jin, L., JOUNAY, F., Niger, P., Kamite, Y., DeLord,
Pseudowire", draft-ietf-pwe3-p2mp-pw-requirements-00 (work S., and L. Martini, "Requirements for Point-to-Multipoint
in progress), September 2008. Pseudowire", draft-ietf-pwe3-p2mp-pw-requirements-02 (work
in progress), January 2010.
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006. Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for
Layer 2 Provider-Provisioned Virtual Private Networks", Layer 2 Provider-Provisioned Virtual Private Networks",
RFC 4665, September 2006. RFC 4665, September 2006.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling", (VPLS) Using BGP for Auto-Discovery and Signaling",
skipping to change at page 26, line 4 skipping to change at page 26, line 15
Authors' Addresses Authors' Addresses
Yuji Kamite Yuji Kamite
NTT Communications Corporation NTT Communications Corporation
Granpark Tower Granpark Tower
3-4-1 Shibaura, Minato-ku 3-4-1 Shibaura, Minato-ku
Tokyo 108-8118 Tokyo 108-8118
Japan Japan
Email: y.kamite@ntt.com Email: y.kamite@ntt.com
Frederic Jounay Frederic Jounay
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
France France
Email: frederic.jounay@orange-ftgroup.com Email: frederic.jounay@orange-ftgroup.com
Ben Niven-Jenkins Ben Niven-Jenkins
BT Velocix
208 Callisto House, Adastral Park 326 Cambridge Science Park
Ipswich, IP5 3RE Milton Road, Cambridge
CB4 0WG
UK UK
Email: benjamin.niven-jenkins@bt.com Email: ben@niven-jenkins.co.uk
Deborah Brungard Deborah Brungard
AT&T AT&T
Rm. D1-3C22, 200 S. Laurel Ave. Rm. D1-3C22, 200 S. Laurel Ave.
Middletown, NJ, 07748 Middletown, NJ, 07748
USA USA
Email: dbrungard@att.com Email: dbrungard@att.com
Lizhong Jin Lizhong Jin
Nokia Siemens Networks ZTE Corporation
Building 89, 1122 North QinZhou Road, 889, Bibo Road
Shanghai, 200211 Shanghai, 201203
P.R.China China
Email: lizhong.jin@nsn.com Email: lizhong.jin@zte.com.cn
 End of changes. 29 change blocks. 
78 lines changed or deleted 84 lines changed or added

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