Subject: draft-ietf-l2vpn-vpls-mcast-reqts-02

From: Shane Amante <[email-masked]>
Date: Sun, 30 Jul 2006 22:58:23 -0600

Yuji, et. al,

Below are some comments & questions I have related to your I-D.  In 
addition, I have a number of fairly minor editorial nits, which I will 
mail to you separately.

Thank you for your work on this.

-shane

---cut here---

In Section 4.1.2:
       -  A solution SHOULD support IP multicast of customers with
       the care of their Layer-3 multicast routing state.
I'm not clear on what you mean by "with the care of".  Do you mean 
something along the lines of "by observing their Layer-3 multicast 
routing protocols/state"?

Also, in section 4.1.2:
    -  In a solution, Layer-2 control frames (e.g., BPDU, 802.1ag CFM)
       SHOULD be flooded to all PE/CEs in a common VPLS instance.  A
       solution SHOULD NOT change or limit the flooding scope to remote
       PE/CEs in terms of end-point reachability.
Just so I am clear on why the first sentence above says "SHOULD" and not 
"MUST" is because the SP, at its discretion, may filter Layer-2 control 
frames, (for example, on it's PE's or other network infrastructure 
elements)?

In Section 5.4, I'm not clear on what you mean by the second sentence in 
the following paragraph:
    Multicast specific characteristics that may be monitored are, for
    instance, multicast statistics per stream, delay and latency time
    (time to start receiving a multicast group traffic across the VPN).
    You can also see about variation in delivery time of a multicast
    packet to different destination.
In the second sentence it does not sound like you are speaking about 
jitter (a.k.a.: delay variation) for packets inside one multicast stream 
from a single source PE to a single receiver PE.  Correct?  Instead, 
you're looking to compare the difference in one-way delay (for a single 
multicast group/stream?) from a single source PE to multiple receiver 
PE's?  If so, could you please clarify this?

In Section 5.10, I think the following paragraph needs some 
word-smithing to make it more clear.  Can you change the following from 
this:
    However, a multicast VPLS, by nature, is the one which allows to pick
    up individually customer's multicast and unicast logically in order
    to solve resource waste issue.  Thus this point will bring some
    customers more or less a new concern that they might have complicated
    situations in case of failure in either unicast or multicast only.
to this:
    A multicast VPLS solution may decouple the path that a customer's
    unicast and multicast traffic follow through a SP's Backbone, in
    order to provide the most optimal path for mutlicast data traffic.
    This may cause concern among some multicast VPLS customers who desire
    that, during a failure in the SP's network, both unicast and
    multicast traffic fail concurrently.

Also, in Section 5.10, I'm not clear what you mean by the following 
statements:
    Note that how serious this issue is depends on each customer's stance
    in Ethernet operation.  For example, if all CEs are IP routers i.e.,
    if VPLS is provided for LAN Routing application, such the customer
    might not need to care about it because both connectivity is assured
    in IP layer.
Are you trying to say that if the CE routers are running an IGP (e.g.: 
OSPF/IS-IS) and a multicast routing protocol, (e.g.: PIM), then liveness 
of both the unicast and multicast paths will be "adequately" detected by 
the CE's?

Assuming that is the case, you may also want to point out above that 
this doesn't guarantee that unicast and multicast traffic are not 
guaranteed to follow the same path in the SP's Backbone network, but 
does mitigate this issue to some degree.

In Section 6.5.1,
    Also it MAY be possible:
    o  with an IP multicast group and/or channel granularity
Do you mean "with a _customer_ IP multicast group and/or channel 
granularity"?

In Section 6.5.4, I would suggest rewording the following paragraph FROM:
          In particular, such mechanisms SHOULD be able to detect
          multicast failure quickly on par with unicast cases.  It needs
          to obviate the cases where multicast has been in failure for
          long time while unicast remains alive; such a situation, in
          many cases, might end up in complicated troubles in customer
          applications which use a combination of them.
TO:
          In particular, such mechanisms SHOULD be able to detect a
          multicast failure quickly, (on par with unicast cases).  It
          also should avoid situations where multicast traffic has been
          in a failure state for a relatively long time while unicast
          traffic remains operational.  If such a situation were to
          occur, it would end up causing problems with customer
          applications that depend on a combination of unicast and
          multicast forwarding.

Also, in Section 6.5.4, I would suggest rewording the following 
paragraph FROM:
          However, in multicast, as there are many receivers pertaining
          to a particular unidirectional traffic, possibly the number of
          potential detecting points also grows, which will raise
          scalability concern.  Consequently, a fault detection solution
          SHOULD scale well with consideration of key metrics described
          in section 6.1.2.
TO:
          With multicast, there may be many receivers associated with a
          particular mulitcast stream/group.  As the number of receivers
          increases, the number of places (typically nearest the
          receivers) required to detect a fault will increase
          proportionately.  This raises concerns over the scalability of
          fault detection in large multicast deployments.  Consequently,
          a fault detection solution SHOULD scale well; in particular, a
          solution should consider key metrics for scalability as
          described in section 6.1.2.