Comments on "draft-ietf-l2vpn-vpms-frmwk-requirements"

[Yuji Tochio <tochio at jp.fujitsu.com>]

Dear Editors and all,

FYI:
Here are my comments on this I-D through offline discussion with Yuji
(Mr. Kamite) though some had been posted by Greg

<<Clause 4.3>>
I-D says:
As far as synchronization in a PSN environment is concerned,
different mechanisms can be considered to provide frequency and phase
clock

"clock" should be replaced by "synchronization"
Or in generic manner, "to provide frequency and phase clock " may be
removed.


<<Clause 6.1.2 (& 6.4)>>
In general, It seems that contents of those clauses are overlapped
to each other so that editorial clean up should be required.

I think first these sentences are enough in 6.1.2 and the rest
of those in 6.1.2 with figure 2 should be merged to 6.4

A solution MUST support multiple sender topologies in one VPMS
instance, where a common receiver group is reachable from two or more
senders. This means that a solution needs to support having multiple
P2MP topologies in the backbone whose roots are located apart in a
common service. Thus a solution will also need to support protection
and restoration mechanism combining these multiple P2MP
topologies. (See section 6.4 too).


And even if in clause 6.1.2., more clarification of Figure 2 should be
considered. The most important is to clarify AC3 & 4 or PE3 & PE4.
AC3 or 4 seems to share VPMS instance from either PE1 or
PE2. This point should be clarified.

For example, proposed is

Replace

Note that every receiver has only to have one AC connected to
each PE to receive traffic. (in Figure 2, AC3 and AC4 respectively).
Thus a solution will also need to support protection
and restoration mechanism combining these multiple P2MP
topologies. (See section 6.4 too).

by

Note that every receiver has only to have one AC connected to
each PE to receive traffic. In the case of Figure 2, PE3 and PE4
should select traffic from PE1 or PE2 and AC3 and AC4 should be
single as attached to PE3 and PE4 respectively.
Thus a solution will also need to support protection
and restoration mechanism combining these multiple P2MP
topologies. (See section 6.4.2 too).

Of cource, this could be better in align with 6.4.1.2


<<Clause 6.1.3>>
I-D says:
　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.

Since there are some alternatives for this way such that providing
multiple VPWS (as reverse) or mp2p instance
So I ask for relaxing the descrption, i.e. replace "the simplest way" by
"the example"

I-D says:
Such bi-directional instances can be easily created if two distinct
ACs are provisioned for sending and receiving exclusively

I am not sure this assumption (= exclusively) is easiest.
I also ask for relaxing the descrption.


<<Clause 6.1.4>>
In general, I think these subclauses should focus on
- Protetion/redundancy topology support as 6.1.4.1
- Traffic support in Protetion/redundancy as 6.1.4.1
As I wrote above, this is overlapped with 6.1.2
Figure 2 should be moved here and text should be merged with latter
of 6.1.2


<<Clause 6.1.4.1>>
There are some areas that form protection/redundancy:
(1) (Sender) CE to (Sender/Ingress) PEs
(2) VPMS instances or inside PSN
(3) (Receiver) PEs to Receiver CE

This clause should indicate this point, where protection/redundancy
is required. (The use of dual home may miss (2))


<<Clause 6.1.4.2>>
As I wrote above, this is overlapped with 6.1.2
Figure 2 should be moved to this clause here and text should be merged
with latter of 6.1.2


Regards,
Yuji Tochio