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

From: "Yuji KAMITE" <[email-masked]>
Date: Tue, 01 Aug 2006 16:26:49 +0900

Hi Shane,

Thank you for lots of valuable feedback.
Please see below inline my comments.

Regards,
-Yuji

> -----Original Message-----
> From: Shane Amante [mailto:[email-masked]] 
> Sent: Monday, July 31, 2006 1:58 PM
> To: [email-masked]
> Subject: draft-ietf-l2vpn-vpls-mcast-reqts-02
> 
> 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"?

Yes, observing L3 protocol is expected as one way to expedite IP multicast.
What about the rephrasing like this?: 

   -  A solution SHOULD support a way to facilitate IP multicast forwarding
      of the customers.   It MAY observe Layer-3 information (i.e., multicast
      routing protocols and state) to the degree necessary, but any information
      irrelevant to multicast transport SHOULD NOT be consulted.

> 
> 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)?

It makes sense.  Depending on each provided service spec, some SPs are
possibly filtering control frames out of necessity (All PE/CEs do not
alway receive them).  From that standpoint , I thought MUST is too strong,
SHOULD would be proper level. 

For clarifying, what do you think about adding one sentense at the last below? :

     -  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.  However, it MAY be allowed
        to filter them for some necessity at SP's discretion.

> 
> 
> 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?
> 

The latter was my original idea.  "Delay variation" doesn't look
a good word as you pointed out.  But on the other hand,
jitter is also important factor.
So, what is this change like?: 

   Multicast specific characteristics that may be monitored are, for
   instance, multicast statistics per stream, one-way delay, jitter and
   latency time (time to start receiving a multicast group traffic across the
   VPN).  You can also compare the difference in one-way delay for a single 
   multicast group/stream from a single source PE to multiple 
   receiver PEs.

> 
> 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.
> 

Agreed.  A good way of putting it.

> 
> 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?

Yes.

> 
> 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.

It make sense.  By incorporating your idea, I'll change as follows:

   Note that how serious this issue is depends on each customer's stance
   in Ethernet operation.  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.  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 detected by the CEs.  This does not guarantee
   that unicast and multicast traffic are 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"?

Yes, I do.  I'll correct it.

> 
> 
> 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.

Agreed.

> 
> 
> 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.
> 

Agreed.

---

From: Shane Amante <[email-masked]>
Date: Sun, 13 Aug 2006 14:58:19 -0600

Hi Yuji,

Sorry for the delayed response.  I agree with nearly all your  
suggested changes/clarifications.  Please see below for some  
additional comments.

-shane

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

[--snipped--]

>         to filter them for some necessity at SP's discretion.

I think the addition of the last sentence may lead to more confusion,  
plus I think there's enough room (with the existing SHOULD/SHOULD NOT  
text) for one to infer that SP's may filter at their discretion.  I  
was just asking for clarification, but don't think the last sentence  
is necessary.

>    multicast group/stream from a single source PE to multiple

I'd suggest some minor editing of the last sentence as follows:
---cut here---
An operator may also wish to compare the difference in one-way delay  
for a solitary multicast group/stream from a single, source PE to  
multiple receiver PE's.
---cut here---

[--snipped to end--]