Subject: Comments to VPMS Requirements

From: Greg Mirsky <[email-masked]>
Date: Fri, 23 Jan 2009 16:36:47 -0500

Dear Yuji and All,
please find my notes to the document below:

   - Section 4.1

"However, if only P2MP connectivity is required, the traffic between
different receivers is not always needed, and traffic from receiver to
sender is not always needed, either."
I believe that in P2MP constructs connectivity between leafs is not just
"not always needed" but prohibited. To enforce this might require extra
efforts if P2MP uses VPLS. I propose changing this to:
"However, if only P2MP connectivity is required, the traffic between leafs
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."

   - Section 4.2

I'm not sure how second paragraph of the section 4.2 is related to the
subject of P2MP scenarios in TDM. And perhaps "drop-and-continue" TDM-based
applications might be added as one of use cases that can benefit from VPMS.

   - Section 5

Following seems somewhat ambiguous since frames might not be just duplicated
but replicated multiple times on the same node (PE or P)
"The SP's network (PE as well as P) has a role to duplicate frames so that
the traffic source does not need to send multiple frames to individual
receivers."
I think that it can be clarified as:
"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."

Is following a requirement or a statement:
"In a VPMS, PEs will be connected by PW technology which may include P2MP
traffic optimization ..."
If this is a statement that perhaps it can be re-worded as more probable
wording like
"PW technology with P2MP traffic optimization might be used in a VPMS ..."

I don't understand if following is a requirement or statement of benefit:
"Also routed backbone provides IP or MPLS-enabled PSN tunnels for
transporting the PW traffic."

   - Section 6.1.2 Multiple Source Support

I understand this section as expression of requirement of VPMS's high
availability. Is that correct understanding? If so, then I'd propose to
change the name of the section to "VPMS High Availability" or remove the
section all together since the subject is covered in section 6.4 Protection
and Restoration. For one I'd suggest removing reference to support of
multiple senders/sources in VPMS and mention redundant ACes. How to provide
high availability in VPMS, I believe, is outside of the scope of the
document but it is worth mentioning some of possible mechanisms, e.g.
redundant ACes, redundant p2mp PWs, p2mp LSP protection, etc.

   - Section 6.1.3 Reverse Traffic Support

"The simplest way to accomplish this is to provide different VPMS instances
for reverse traffic, i.e. a sender CE is a receiver of another VPMS
instance."
I would argue that this is the simplest and cleanest way to achieve stated
goal because it leads to N reverse VMPSes for a VMPS with N receivers. I
think that if application requires support of revese traffic then either it
should be OOB or use VPLS model instead of VPMS.

And perhaps little typo in "That is, the combination between VLAN id and the
flow direction is ..." should be "That is, combination of VLAN id and the
flow direction is ..."

   - Section 7.3

"Auto-discovery will help operators' initial configuration of adding a new
VPN (i.e., VPMS instance), adding/deleting new sender/receiver, and so on."
I think that VPMS instance is created when a sender PE (can we use "s-PE")
and at least one receiver PE (r-PE) been added. Without this minimum
requirement VPMS instance does not exist. If that is correct then only
backup s-PE can be dynamically added/deleted to/from VPMS without destroying
the VPN.

   - Section 7.7.2 Testing

I think that it is useful to explixitly require ability to test not only
connectivity over working P2MP connection but protecting path(s) as well
from s-PE and, possibly, sender CE.

Regards,
Greg