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

From: "Yuji KAMITE" <[email-masked]>
Date: Fri, 08 Sep 2006 17:58:05 +0900

Hi Shane,

Sorry for being late.  I agreed to your suggestions all below.
Please wait for the revision, where I'll incorporate them soon.

Regards,
-Yuji

> -----Original Message-----
> From: Shane Amante [mailto:[email-masked]] 
> Sent: Monday, August 14, 2006 5:58 AM
> To: Yuji KAMITE
> Cc: [email-masked]
> Subject: Re: draft-ietf-l2vpn-vpls-mcast-reqts-02
> 
> Hi Yuji,
> 
> Sorry for the delayed response.  I agree with nearly all your 
> suggested changes/clarifications.  Please see below for some 
> additional comments.
> 
> -shane
> 
> 
> On Aug 1, 2006, at 1:26 AM, Yuji KAMITE wrote:
> > 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
> >>
> >>
> 
> [--snipped--]
> 
> >> 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.
> 
> 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.
> 
> 
> 
> >> 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.
> 
> 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--]
>