Subject: Review of draft-ietf-l2vpn-vpms-frmwk-requirements-05.txt

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Wed, 27 Mar 2013 11:01:48 +0000

Working group,

I have been asked by the chairs to review
draft-ietf-l2vpn-vpms-frmwk-requirements-05.txt.

Please find my comments embedded below, prefixed by MB>.

In summary, I think this draft needs another revision clarifying the open
points in the use 
cases, and addressing the questions below.

Best regards

Matthew

=============================

[...snip...]

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119] .

MB> this is an informational draft, so RFC2119 language might not be
appropriate.

[...snip...]

4.  Use Cases

4.1.  Ethernet Use Case

4.1.1.  Ethernet-based multicast stream

   For multicast traffic delivery, there is a requirement to deliver a
   unidirectional P2MP service in addition to the existing P2P service.
   The demand is growing to provide private (P2MP native Ethernet)
   services, for various applications such as IP- based delivery of TV
   broadcasting, content delivery networks, etc.  Moreover, many digital
   audio/video devices (e.g., MPEG-TS, HD-SDI) that support Ethernet
MB>                           ^^^^^^^  ^^^^^^
MB> Please can you expand acronyms on first use, and provide references to
MB> these. This comment applies throughout the draft.
     
   interfaces are becoming available, which will make Ethernet P2MP
   service more common.  Also there are some applications that naturally
   suited to static transport of VPMS.  For example, MPEG-TS/IP/Ethernet
   in DVB-H is typically static broadcast without any signaling in the
   upstream direction.  VPMS could be a possible solution to provide
   these kinds of networking connectivity over PSNs.

   Currently VPLS [RFC4761][RFC4762] is able to give P2MP-type
   replication for Ethernet traffic.  Native VPLS already supports this
   capability via a full mesh of PWs, and an extension to optimize
   replication is also proposed [I-D.ietf-l2vpn-vpls-mcast] as an
   additional feature.  However, VPLS by nature requires MAC-based
   learning and forwarding, which might not be needed in some cases by
   particular users.  Generally, video distribution applications use
   unidirectional P2MP traffic, but may not always require any added
   complexity of MAC address management.  In addition, VPLS is a service
   that essentially provides any-to-any connectivity between all CEs in
   a L2VPN as it emulates a LAN service.  However, if only P2MP
   connectivity is required, the traffic between leaf nodes is not
   allowed.  It might require extra efforts to guarantee this behavior
   in VPLS.  And in some P2MP scenarios there no traffic from leafs to
   root.  In these cases, VPMS is a service that provides much simpler
   operation.

   Note that VPMS provides single coverage of receiver membership; that
   is, there is no distinct differentiation for multiple multicast
   groups in one VPN.  All traffic from a particular Attachment Circuit
   (AC) will be forwarded toward the same remote receivers, even if the
   destination MAC address is changed.  Basically in VPMS, destination
   MAC addresses are not used for forwarding, which is significantly
   different from VPLS.  If MAC-based forwarding is preferred (i.e.,

Kamite, et al.           Expires April 25, 2013                 [Page 6]

Internet-Draft       VPMS Framework and Requirements            Oct 2012

   multicast/unicast differentiation by MAC address), VPLS should be
   chosen rather than VPMS.

4.1.2.  Ethernet-based time/frequency synchronization

   Nowadays there exist several solutions to provide synchronization for
   time and/or frequency reference by the packet-based technology of
   Ethernet.  For example, PTPv2 (Precision Time Protocol version 2) is
   a time-transfer protocol defined in the IEEE 1588-2008 standard.  It
   provides precise synchronization of packet-based networks (e.g.,
   Ethernet).  It adopts two-way time transfer approach for
   synchronization.  Time transfer protocol may be operated in multicast
   or unicast mode in both directions, and it is mapped over the
   Ethernet/IP/UDP protocol stack.

   Moreover, PTPv2 telecom profile is now discussed in ITU-T that
   defines a set of capabilities and extensions required to support
   telecommunication applications.  It aims at providing frequency
   distribution with higher level of accuracy.  It allows unicast mode
   or the mix of unicast/multicast modes for the transmission of the PTP
   messages.

   In this aspect, VPMS might be considered as a potential packet-based
   infrastructure to deliver multicast messages in PTPv2 with efficient
   forwarding.  Note, however, in PTPv2 telecom profile, multicast
   transport may not always be supported in all the parts of a telecom
   network because multicast might sometimes generate additional PDV
   (packet delay variation) compared to unicast.  Therefore, VPMS use
   case and the corresponding solution for this purpose will need more
   study in the future (e.g., PDV issue to be checked).
   
MB> The paragraph above seems to imply that you are not sure that there
MB> are requirements that VPMS can address for this use case. I think
MB> you are saying that VPMS should not introduce significant PDV. Please
MB> can you clarify this section? If it is clear that the requirement not
MB> to exceed a certain PDV cannot be met with multicast, then doesn't
that 
MB>  rule out the use of VPMS for this use case?

4.2.  ATM-based Use Case

4.2.1.  ATM-based multicast stream

   A use case of ATM-based service in VPMS could be to offer the
   capability for service providers to support IP multicast wholesale
   services over ATM in case the wholesale customer relies on ATM
   infrastructure.  The P2MP support alleviates the constraint in terms
   of replication for ATM to support IP multicast services.

   Another use case of VPMS for ATM is for audio/video stream
   applications.  Today many digital TV broadcasting networks adopt ATM-
   based distribution systems with point-to-multipoint PVPs/PVCs.  The
   transport network supports replicating ATM cells in transit nodes to
   efficiently deliver programs to multiple terminals.  For migrating
   such ATM-based networks onto IP/MPLS-based networks, VPMS is
   considered to be a candidate solution.

MB> This section seems to deal with two scenarios. One is IP multicast,
MB> where multicast replication of IP packets transported in ATM VCs is
MB> required. The other is emulating native ATM multicast, where ATM cells
MB> are replicated without regard to their content. The first case seems
MB> to be an L3VPN multicast use case with ATM transport, because you need
to 
MB> process/replicate
MB> and forward based on the IP packet header, not an L2VPN multicast use
case.
MB> If so, is this in scope of VPMS?

Kamite, et al.           Expires April 25, 2013                 [Page 7]

Internet-Draft       VPMS Framework and Requirements            Oct 2012

4.3.  TDM-based Use Case

4.3.1.  TDM-based multicast stream

   Today the existing VPWS already supports TDM emulation services
   (SAToP, CESoPSN or TDMoIP).  It is a Layer 1 service, not Layer 2
   service; however, a common architecture is being used since they are
   all packet-based emulations over a SP's network.  VPMS is also
   considered to be a solution for such TDM applications that require
   point-to-multipoint topology.

   One use case is TDM-based multicast stream delivery, like video
   delivery.  That is, data duplication is simply provided by Layer 1,
   without using upper layer's multicast protocols.
   
MB> Can you provide more details of this use case? Is this actually a TDM
MB> service, or is it just a TDM interface and you could use e.g. ATM
multicast?
MB> Are there any requirements in terms of preserving the timing
information
MB> that would impact the solution? Also, is efficient clock distribution
MB> a use case (as it is for P2MP TDM PW).

5.  Reference Model

   The VPMS reference model is shown in Figure 1.

       +-----+ AC1                                     AC2 +-----+
       | CE1 |>---+     ------------------------      +--->| CE2 |
       +-----+    |    |      VPMS A's P2MP     |     |    +-----+
        VPMS A    |  +------+ Connection    +------+  |    VPMS A
        Sender    +->|......>...+.......... >......|>-+    Receiver
                     | VPMS |   .           | VPMS |
                     | PE1  |   .           | PE2  |
                  +-<|......<.. . ....+.....<......|<-+
                  |  +------+   .     .     +------+  |
       +-----+    |    |        .     .         |     |    +-----+
       | CE4 |<---+    |Routed  .     . VPMS B's P2MP +---<| CE3 |
       +-----+ AC4     |Backbone.     . Connection     AC3 +-----+
        VPMS B         |        .     .         |          VPMS B
        Receiver       |      +-v-----v-+       |          Sender
                        ------| .     . |-------
                              | . VPMS. |
                              | . PE3 . |
                              +---------+
                                v     v       VPMS A:
                                |     |         Root AC  : AC1
                             AC5|     |AC6      Leaf AC  : AC2, AC5
                                v     v       VPMS B:
                           +-----+   +-----+    Root AC  : AC3
                           | CE5 |   | CE6 |    Leaf AC  : AC4, AC6
                           +-----+   +-----+
                           VPMS A     VPMS B
                   
MB> I think 'routed backbone' correspond to 'PSN' in L2VPN and PWE3
terminology.
MB> I suggest updating this terminology accordingly.

Kamite, et al.           Expires April 25, 2013                 [Page 8]

Internet-Draft       VPMS Framework and Requirements            Oct 2012

                           Receiver   Receiver

                     Figure 1: Reference Model for VPMS

   A VPMS instance is defined as a service entity manageable in the VPMS
   architecture.  A single VPMS instance provides an isolated service
   reachability domain to each CE, so it corresponds to a so-called
   "VPN" as it allows communication among a specific set of sites.  A
   single VPMS instance provides a unique point-to-multipoint L2VPN
   service.  In Figure 1, there are two VPMS instances shown, VPMS A and
   VPMS B. In principle, there is no traffic exchange allowed between
   these different instances, so they are treated as different VPNs.

   In a VPMS, a single CE-PE link connection is used for transmitting
   frames for delivery to multiple remote CEs, with point-to-multipoint
   duplication.  The SP's network (PE as well as P) has a role to
   replicate frames so that the sender's CE does not need to send
   multiple frames to individual receivers.

   Like VPWS, an Attachment Circuit (AC) is provided to accommodate CEs
   in a VPMS.  In a VPMS, an AC attached to a VPMS MUST be configured as
   "root" (sender) or "leaf" (receiver) not both.  Any AC is associated
   
MB> s/..not both/...,but not both
   
   with the role of either sending side (Tx) or receiving side (Rx) from
   the view of the CE.  These will be named the root (sender) AC and
   leaf (receiver) AC respectively.  Unless reverse traffic is
   optionally supported, a root AC does not transmit traffic back to a
   CE at upstream side, likewise a leaf AC does not receive traffic from
   a CE at downstream side.  In Figure 1, AC1 and AC3 are configured as
   root ACs while AC2, AC4, AC5 and AC6 are configured as leaf ACs.  In
   VPMS A, CE1 could send traffic via AC1, and CE2 and CE5 could receive
   the traffic.

   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
   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
   leaf) will automatically determine them.

   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
   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
   and a VPMS instance.  For example, all traffic from CE1 to PE1

Kamite, et al.           Expires April 25, 2013                 [Page 9]

Internet-Draft       VPMS Framework and Requirements            Oct 2012

   (through AC1) is mapped to VPMS A (to CE2 and CE5).

   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
   this VPMS framework.  P2MP connection is a logical entity between PE/
   ACs in a given VPMS instance that transfers unidirectional traffic
   transparently from one local ingress AC to one or more remote egress
   ACs.

   Similar to other L2VPN mechanisms, the VPMS architecture is based on
   PWs which may be using through IP or MPLS-enabled PSN tunnels over a
   routed backbone.
   
MB> If this requires PWs, then I propose that we constrain this to PWs
MB> defined by PWE3, which are MPLS PWs over an IP or MPLS PSN.

    That is, every P2MP connection can be instantiated
   by PW technology that supports P2MP traffic optimization (i.e., P2MP
   PW.  See section 7.2.).  P2MP traffic optimization will provide the
   benefit of traffic replication for high bandwidth efficiency.
   
MB> I think you mean that replication of packets by nodes in the PSN
improves
MB> bandwidth efficiency when compared with replication by the CE.
   
   That
   is, the sender CE has only to transmit one stream towards the PE and
   it does not have to replicate traffic.

   Regarding end-to-end traffic topology between the ACs, a single VPMS
   instance (i.e., one VPN) may correspond to a single P2MP connection.
   In Figure 1, VPMS A (one instance) has one P2MP connection (from AC1
   to AC2 and AC5).  However, there is also a case that a single VPMS
   consists of two or more P2MP connections grouped, which is typically
   used for multi-source or redundancy.  The details are given in
   section 6.4 and 6.5.

   VPMS can support various Layer 2 protocol services such as Ethernet,
   ATM, etc.
   
MB> I think it is worth breaking this into an explicit list of layer 2
MB> protocols that must be supported, for example:
MB> VPMS must support Ethernet, ATM and TDM P2MP services.

6.  Customer Requirements

MB> I think these are a list of service requirements, so I suggest
renaming 
MB> section 6 accordingly.

6.1.  Service Topology

6.1.1.  Point-to-Multipoint Traffic Support

   A solution MUST support unidirectional point-to-multipoint traffic
   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
   which are located at remote sites, but also the local CEs which are
   connected to the same root PE (i.e., when a root AC and some of leaf
   ACs are co-located).  If there is only one receiver in the instance,
   it is considered equivalent to unidirectional point-to-point traffic.

6.1.2.  Reverse Traffic Support

   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

Kamite, et al.           Expires April 25, 2013                [Page 10]

Internet-Draft       VPMS Framework and Requirements            Oct 2012

   scenarios for this, such as stream monitoring through a loopback
   mechanism, control channels which need feedback communication etc.  A
   possible way to accomplish this is to provide different VPMS
   instances for reverse traffic, i.e. a root CE is a receiver of
   another VPMS instance.  However, provisioning different VPNs for a
   particular customer would make its management task more complex.  It
   is desired to have an alternative solution for supporting reverse
   traffic flow.  This section provides additional requirements for this
   optional capability.

   Therefore, a VPMS solution MAY support reverse traffic from a leaf AC
   to a root AC.  Each reverse path is basically given in a P2P
   (unicast) manner.
   
MB> I suggest rephrasing: "Each reverse path is P2P i.e. unicast.
   
   In other words, each leaf of the P2MP tree can
   individually send back traffic to the root.  For this purpose a VPMS
   instance MAY have more than one reverse P2P connections as network
   entity; However, such network entities MUST have a common indetifier
   that enables themselves to be managed together in the same VPN.  Thus
   any PWs used for such connections are expected to be assigned a
   common VPMS instance ID (i.e., VPN ID).

   Note, a VPMS does not assume any-to-any multipoint reachability.
   Therefore, in principle, every leaf AC does not need to exchange
   traffic directly with other leaf ACs even if reverse traffic is
   supported.
   
MB> Is there a requirement that the VPMS must not forward traffic between
leaf
MB> ACs?

   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
   ACs.  P2MP connection is given for traffic in the forward direction.
   Unidirectional P2P connection is also provided for traffic in the
   reverse direction, from AC4 to AC1.  Other reverse P2P connections
   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-
   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
   AC4 respectively).  But it is an implementation matter if Tx and Rx
   traffic are conveyed on the same physical link or separate links.  It
   is also possible that a root PE multiplexes two ore more reverse
   traffic from different leaf ACs and transmits it to an upstream CE
MB>    ^^^^ traffic flows              ^^^^^^^^^forwards the resulting
flow               

   over the same local physical link.

   Note, in most implementations of VPWS today, every AC is always
   considered bidirectional.  In contrast, in VPMS, every AC can be
   chosen unidirectional (if it is a totally unidirectional service), or
   
MB> I suggest removing the word 'chosen'

   bidirectional (if reverse traffic is supported).

Kamite, et al.           Expires April 25, 2013                [Page 11]

Internet-Draft       VPMS Framework and Requirements            Oct 2012

          +-----+ <-- Rx   (bidirectional)
          | CE1 |--------------+
          +-----+ --> Tx       |
    VPMS A Sender              |
                           AC1 |
                             +----------+ VPMS
                             | . .      | PE1
                             | .  ....  |
                      -------| .      . |--------
                     |  P2MP +-v------^-+        |
                  Connection   .      .          |
                    (forward)  +      .          |
                     |         .      .          |
                   +------+  . . .    .        +------+
                +-<|......<..  .  ..  .  ......>..... |>-+
                |  | VPMS |    .      .        | VPMS |  |
             AC2|  | PE2  |    .      .        | PE3  |  |AC3
                |  +------+    .      .        +------+  |
      +-----+   |    |         .      . P2P      |       |   +-----+
      | CE2 |<--+    | Routed  .      . Connection       +-->| CE3 |
      +-----+ <--    | Backbone.      . (reverse)|       --> +-----+
     VPMS A     Rx   |       +-v------^-+        |        Rx VPMS A
     Receiver         -------| .      . |--------            Receiver
                             | .  ....  |
                             | . .      | VPMS
                             +----------+ PE4
                            AC4|
                               |
                               |           <-- Tx   +-----+
                               +--------------------| CE4 |
                           (bidirectional) --> Rx   +-----+
                                                    VPMS A
                                                    Receiver
MB> Replace 'routed backbone' with PSN

                       Figure 3: Reverse traffic support

6.2.  Transparency

   A solution is intended to provide Layer-2 traffic transparency.
   Transparency SHOULD be supported per VPMS instance basis.  In other
   words, Layer-2 traffic can be transparently transported from a local
   CE to remote CEs in a given instance.  Note, however, if service
   delimiting fields (VLAN Id in Ethernet, VPI/VCI in ATM, DLCI in FR
   etc.) are assigned and possibly can be changed by the SP, the Layer-2
   traffic is not necessarily transparent.
   
MB> does VPMS need to support FR?

    It will depend on the SP's
   choice if they assign it to each AC.  Hence, it could be that some of
   the leaf CEs are receiving traffic that has different delimiting

Kamite, et al.           Expires April 25, 2013                [Page 12]

Internet-Draft       VPMS Framework and Requirements            Oct 2012

   fields than the traffic for the other leaf CEs.

MB> any switched service is by definition not transparent to the L2
header. Maybe
MB> you mean that the VPMS should be transparent to the L2 service to the
same
MB> extent that the native multicast service being emulated would be?

   The VPMS solution SHOULD NOT require any special packet processing by
   the end users (CEs).

6.3.  Quality of Service (QoS)

   A customer may require that the VPMS service provide guaranteed QoS.
   In particular, for real time applications which are considered common
   in point-to-multipoint delivery, delay and loss sensitive traffic
   MUST be supported.  The solution SHOULD provide native QoS techniques
   for service class differentiation, such as IEEE 802.1p CoS for
   Ethernet.

   For bandwidth committed services (e.g., ATM CBR (Constant Bit Rate)),
   a solution SHOULD guarantee end-to-end bandwidth.  It MAY provide
   flow admission control mechanisms to achieve that.
   
MB> Flow admission is not enough on it own to guarantee bandwidth and other
MB> QoS objectives. I sugget you just say 'Flow admission control
mechanisms
MB> may be provided'.

6.4.  Multi-Source Support

   A VPMS solution SHOULD support multiple sources in each VPN.  That
   is, two or more sender CEs can exist in the same VPMS instance.  Each
   sender CE SHOULD be able to be connected to physically separate root
   PEs, which will facilitate flexible topology design.

   Additionally, traffic from sender CEs MAY have a common single
   coverage to receiver CEs, i.e., data from any sources can reach the
   same group of receivers.  For example, in TV provisioning scenario,
   customers may need to receive two or more TV channels from different
   sources.  In figure 3, suppose there are 7 hosts, CE1 to CE7 which
   belong to a given VPMS instance A. CE1, CE2 and CE3 are common
   sources of this VPN, and are attached to different PEs respectively.
   Traffic from each source can reach the same group of receivers, CE4
   to CE7.

   This kind of scenario will require multiple P2MP connections in a
   single VPMS instance (i.e., VPN).  Each P2MP connection's root might
   be a completely different CE/AC, but leaf CE/ACs are overlapped.
   Since this is basically the same requirement as dual-homed scenario,
   see section 6.5.1 for details.

Kamite, et al.           Expires April 25, 2013                [Page 13]

Internet-Draft       VPMS Framework and Requirements            Oct 2012

                    VPMS A +-----+     +-----+ VPMS A
                    Sender | CE1 |     | CE2 | Sender
                           +-----+     +-----+
                             |          |
      +-----+ VPMS A         v AC1      v AC2
      | CE3 | Sender        +----+     +----+
      +-----+          -----|VPMS|-----|VPMS|-----
          \           |     | PE1|     | PE2|     |
           \          |     +----+     +----+     |
            \         |                           |
             \ AC3  +----+                      +----+
              +---->|VPMS|                      |VPMS|  AC5    VPMS A
                    | PE3|  Routed              | PE4|-----+   Receiver
                    +----+  Backbone            +----+     |   +-----+
                   /  |                           |  \     +-->| CE5 |
              AC4 /   |                           |   \        +-----+
                 /    |                           |    \ AC6
     +-----+    /     |           +----+          |     \   +-----+
     | CE4 |<--+       -----------|VPMS|----------       +->| CE6 |
     +-----+                      | PE5|                    +-----+
      VPMS A                      +----+                    VPMS A
      Receiver                      | AC7                   Receiver
                                    v
                                 +-----+
                                 | CE7 | VPMS A
                                 +-----+ Receiver

                       Figure 3: Multi-Source support

MB> The figure numbering seems to be duplicated (Figure 3 is already shown
on Pg 12)

6.5.  High Availability

[...snip...]

6.6.  Security

   The basic security requirements from the view of customers are raised
   in section 6.5 of [RFC4665].  It also applies to VPMS.

   In addition, a VPMS solution MAY have the mechanisms to activate the
   appropriate filtering capabilities (for example, MAC/VLAN filtering
   etc.), and it MAY be added with the control mechanism between
   particular sender/receiver sites inside a VPMS instance.  For
   example, in Figure 1, filtering can be added such that traffic from
   CE1 to CE4/CE5 is allowed but traffic from CE1 to CE6 is filtered.

MB> But CE4 is not in the VPMS instance for which CE1 is a root, so why
should
MB> it receive traffic from CE1? Likewise, CE6 cannot receive traffic from
CE1
ME> because it is in a different VPMS. This assumes that we can treat each
MB> VPMS and its associated ACs and CEs as logically separate. The text
following 
MB> Figure 1 seems to imply that each VPMS
MB> is isolated from each other VPMS. I think it would be
MB> clearer if the architecture was described in that manner. That does
not 
MB> stop the physical device that hosts a CE from participating in multiple
MB> VPMS instances.

6.7.  Misordering Prevention

   A solution SHOULD prevent Layer-2 frame misordering when delivering
   customer traffic under normal conditions.  This is often necessary
   for real-time based applications.
   
MB> Isn't this a general L2VPN requirement?

6.8.  Failure reporting

   A solution MAY provide information to the customer about failures.
   For example, if there is a loss of connectivity toward some of the
   receiver CEs, it is reported to the sender CE.

Kamite, et al.           Expires April 25, 2013                [Page 17]

Internet-Draft       VPMS Framework and Requirements            Oct 2012

7.  Service Provider Network Requirements

7.1.  Scalability

   [...snip....]

7.2.1.  Point-to-Multipoint Pseudo Wire

MB> I think this section is getting into too much detail about a candidate
solution.
MB> the P2MP PW requirements draft should reference this draft, but not
the other
MB> was around. I suggest removing this section.

   Regarding PW mechanism, [I-D.ietf-pwe3-p2mp-pw-requirements]
   introduces P2MP PW concept and its requirements, showing two basic
   approaches of providing replication.  One is SS (Single Segment)-PW
   model that provides replication by PSN tunnel such as P2MP LSP (i.e.,
   by outer label layer), and the other is MS (Multi Segment)-PW model

Kamite, et al.           Expires April 25, 2013                [Page 18]

Internet-Draft       VPMS Framework and Requirements            Oct 2012

   that provides replication by multiple interconnected PWs (i.e., by
   inner label layer).  In either case, end-to-end P2MP topology (i.e.,
   P2MP connection) in VPMS is common from the view of ACs.
   Requirements as a provider service specified in this document will be
   commonly applied regardless of P2MP PW's model.

   It is out of scope of this document how to extend and use PW
   mechanisms to realize P2MP connections as a solution.  For example,
   it is under the scope of the solution work how to support forward/
   reverse traffic by a single PW signaling, coupling multiple PWs, or
   other ways.

7.2.2.  PSN Tunneling

   Today, there are several standardized PSN tunneling schemes and their
   control plane protocols that support efficient multicast data
   replication in MPLS, such as P2MP RSVP-TE [RFC4875] and MLDP
   [RFC6388].

   In general, this document does not restrict which control plane
   protocols should be mandatory.  There is no mandatory limitation
   either, about a particular type of data replication topology in PSN
   tunneling (point-to-point, point-to-multipoint and multipoint-to-
   multipoint).

   In VPMS, the preferred type of PSN tunneling will depend on each
   deployment scenario. (e.g., which control plane protocol is available
   in the core and how much of the network resources that operators will
   want to optimize).  The detailed mechanism needs to be specified by
   solution work.

7.2.3.  Static Solution

   VPMS solution MAY support static provisioning for PWs and/or PSN
   tunneling.  Due to some operational reasons, there is a scenario
   where control plane protocol is not used between PSN nodes.  In this
   case, operators will need to have a different method to set up PWs
   and/or PSN tunnels (e.g., by manual configuration or other outband
   interfaces).

MB> I think this requirement should be in the P2MP PW requirements, not in
this
MB> draft.

7.3.  Auto-discovery

   A solution SHOULD support auto-discovery methods that dynamically
   allow VPMS related information to be discovered by the PEs to
   minimize the amount of configuration the SP must perform.

   All of the requirements on discovery described in Section 7.3 of
   [RFC4665] SHOULD be satisfied in VPMS as well.

Kamite, et al.           Expires April 25, 2013                [Page 19]

Internet-Draft       VPMS Framework and Requirements            Oct 2012

   Auto-discovery will help operators' initial configuration of adding a
   new VPN (i.e., VPMS instance), adding/deleting new sender/receiver,
   and so on.

   The candidate information treated in auto-discovery will be as
   follows:

MB> I suggest rephrasing to 'VPMS Auto-discovery requires the following
information':

   -  Information to indentify the location of each PE, e.g., PE router
      ID / IP address
   -  Information to identify the VPMS instance, that is, to identify a
      VPN
   -  Information to identify the type of ACs (root AC or leaf AC)
   -  Information to identify the P2MP connection that binds ACs
   -  Information to show if reverse traffic support is optionally
      desired
   -  SP-related information (AS number, etc. for an inter-provider
      case)

   Following is an example scenario about adding a new leaf PE: suppose
   there are three PEs in an existing VPMS, PE1, PE2, PE3.  PE1 is a
   root PE and has a AC1.  PE2 and PE3 are leaf PEs and have AC2 and
   AC3. every PE has the association among the information described
   above.  Now a new PE4 having an AC4 is provisioned in the existing
   VPMS instance and this AC is configured as leaf.  This information
   will be automatically discovered by the other existing remote PEs
   (i.e., 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 leaf of P2MP connection topology according to P2MP PW
   signaling mechanism.  The ingress PE1 will graft a new leaf (PE4) to
   the already existing P2MP connection which is now created from AC1 to
   AC2/AC3/AC4.  This operation does not require any new configuration
   at the existing PEs.

   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).
   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.,
   multiple source sites, dual-homed access, root PE redundancy etc.).
   Then, auto-discovery mechanism advertises this information to all
   other members PE1/PE2/PE3/PE4, and a new P2MP connection from AC5 to
   AC2/AC3/AC4 is created by PW signaling.

   Note that VPMS instance is created when one root AC and at least one
   leaf AC are added.  In principle VPMS requires such minimum
   provisioning.  Hence in dual-homing case of sender, only backup root
   PE can be dynamically added/deleted to/from VPMS without destroying
   the VPN.

Kamite, et al.           Expires April 25, 2013                [Page 20]

Internet-Draft       VPMS Framework and Requirements            Oct 2012

7.4.  Activation and Deactivation

   [...snip....]

7.7.  Operation, Administration and Maintenance

7.7.1.  Fault Management

7.7.1.1.  Fault Detection

   A solution MUST provide tools that detect reachability failure and
   traffic looping of data transport in a VPMS instance.  If multiple
   root ACs are supported (i.e., multiple P2MP connections are grouped
   together into a single VPMS instance), such tools MUST be able to
   perform distinguishing each P2MP connection.
   ^^^^^^^^^^^^^^^^^^^^^^
MB> s/perform distinguishing / distinguish

7.7.1.2.  Fault Notification

[...snipped to end...]