Subject: RE: I-D ACTION:draft-ietf-l2vpn-vpls-mcast-reqts-02.txt

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

Hi Ben,

>Please find attached my review of draft-ietf-l2vpn-vpls-mcast-reqs-02.
>
>It is mostly editorial corrections/changes but there are some more 
>general
comments too and I have highlighted a number of sections of text that I do not understand.

Thank you very much for lots of input and suggestion.

Regarding editorial changes, I'm going to incorporate it to the next revision soon.

Let me reply on your other comments, please see below.
Generally I think most of them can be reflected at the next revision.
(Please see "YK=>" part.")

Best regards,
-Yuji

------------------------------------
Section 2.1.  Terminology

   - Multicast domain: an area where transmitted multicast data are
      reachable.  In this document, this term has a generic meaning
      which can refer to Layer-2 and Layer-3.  Generally, the Layer-3
      multicast domain is determined by Layer-3 multicast protocol for
      reaching all potential receivers in the corresponding subnet.  The
      Layer-2 multicast domain can be the same as the Layer-2 broadcast
      domain (i.e., VLAN), but it can be smaller than that with
      additional control.
BPN=>The above definition is poorly written.  I understand what it is trying to say but the English isn't clear.

YK=> Do you have any suggestions?  I thought the current paragraph is fine,
    but I'll be happy to incorporate it if you show.
    Today I am just going to change "corresponding subnet" into "corresponding domain" but
    if it's insufficient, please tell me your idea.

3.1.  Motivation

   Today, many kinds of IP multicast services are becoming available.
   Over their Layer-2 VPN service, particularly over VPLS, customers
   would often like to operate their multicast applications across
   remote sites.  Also, multicast service providers using IP-based
   networks are expecting that such Layer-2 network infrastructure will
   efficiently support them.
BPN=>Who is 'them'?  The SPs customer?  Think you should spell out who 'them' refers to?

YK=> I'll change 'them'into 'mutlicast data traffic'.

3.3.1.  Two Perspectives of the Service

   - IP multicast service aspect

      There are some hopeful applications such as Triple-play (Video,
      Voice, Data) and Multicast IP-VPN.  SPs might expect VPLS as an
      access/metro network to deliver multicast traffic in an efficient
      way.
BPN=>The above paragraph doesn't read very well.  Suggest something like "SPs might expect VPLS as an access/metro network to
deliver multicast traffic (such as Triple-play (Video, Voice, Data) and Multicast IP VPNs) in an efficient way.

YK=>OK, I'll change like that.

     [snip]
      also simplicity.  Generally speaking, there is a trade-off between efficiency and simplicity
      in terms of bandwidth usage and state
      maintenance, so the best trade-off comes to be highly expected.
BPN=>I don't understand what the highlighted text is trying to say.

YK=> I mean it is desirable to try to achieve good balance between
     two elements (bandwidth usageand state) -- both should be taken into consideration well.

4.1.1.2.  Unknown Destination Unicast

   Unknown destination MAC unicast needs flooding, but its
   characteristics in terms of service aspect (BPN=>do you mean impact?) are quite different from

YK=> Sorry for confusing. I think this is not needed now.  Let me just change like this:

  Unknown destination MAC unicast needs flooding, but its
   characteristic are quite different from multicast/broadcast. 

4.1.2.  Multicast Packet Types
  [...]
   -  A solution SHOULD support the IP multicast of the customers with
      the care of their Layer-3 multicast routing state.  It MAY consult
      Layer-3 information to the degree necessary, but any information
      irrelevant to multicast transport SHOULD NOT be consulted.
BPN=>I don't understand what the second part of the first sentence is trying to say - suggest removing it and having "A solution
SHOULD support customer IP multicast and MAY consult customer Layer-3 information to the degree necessary, but any information
irrelevant to multicast transport SHOULD NOT be consulted."

YK=> I got a similar comment from Shane too.  I'll change 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.

  [...]

   -  In a solution, Layer-2 frames that encapsulate Layer-3 multicast
      control packets (e.g., PIM, IGMP(for IPv4), MLD(for IPv6)) MAY be
      flooded only to relevant members, with control of limiting
      flooding scope (BPN=>Not sure what this means). 

YK=> I'll change it into "with the goal of limiting flooding scope. "

5.4.  SLA Parameters Measurement

   A solution SHOULD allow providing these parameters with Ethernet
   multicast level granularity (BPN=>I don't understand this sentence).  

YK=> I'll correct it like:
    A solution SHOULD provide these parameters with Ethernet multicast
    group level granularity. 

5.10.  Fate-Sharing between Unicast and Multicast

   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.
BPN=>I don't understand the paragraph above.

YK=> Yes, I already got the same comment too.  I'm going to replace this paragraph with:
 
     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.

   Therefore, there will be an additional requirement for making both
   connectivity coupled.  This means that if either one of them have a
   failure, the other is also deactivated.  If it becomes alive again,
   the other is also activated.
BPN=>Doesn't this conflict with the requirement in 5.5.1 that multicast should not impact unicast fordwarding?

YK=> I don't think so, because 5.10. concludes that it is optional requirement
     that can be applied based on user's decision.  Section 5.5.1. is proposed with SHOULD
     about FIB, throughput and resiliance.
     If one decides to take section 5.10's optional solution, they will naturally accept
     that the unicast connectivity is affected by multicast aliveness (and vice-versa).
     However, as long as there is no outage
     on either side, throughput etc. should be provided with appropriate isolation
     between unicast and multicast.

6.1 Scalability

   However, a multicast VPLS needs additional scalability considerations
   related to its expected enhanced mechanisms.  [RFC3809] lists common
   L2VPN sizing and scalability requirements and metrics, which are
   applicable in multicast VPLS too.  Accordingly, this section deals
   with specific requirements on the premise of it (BPN=>I don't know what this means).

YK=> I'll correct.   s/ on the premise of it/ related to scalability /

6.4.  Discovering Related Information

   The operation of a multicast VPLS solution SHALL be as light as
   possible and providing automatic configuration and discovery SHOULD
   be prioritized.
BPN=>I don't understand the paragraph above.

YK=> Let me change:
        s/SHOULD be prioritized/SHOULD be considered a high priority.

6.5.3.  Performance Management

   A solution SHOULD provide access to:
  [...]
   -  Statistics on decisions related to how client traffic is carried
      on MDTunnels (e.g. "traffic switched onto a multicast tree
      dedicated to such groups or channels") BPN=>I don't understand the above bullet.

YK=> Suppose you have multicast trees inside the core.  PE will 
     transport some multicast traffic by using it.  Actually the tranpsorted
     traffic is chosen based on PIM/IGMP signaling, static or something.
     I think you will need to check the statistics of the usage of MDTunnels.

     Let me suggest to change a bit now:
      "  -  Statistics on decisions related to how client traffic is carried
           on MDTunnels (e.g. "How much traffic was switched onto a multicast tree
           dedicated to such groups or channels") "

     [...]
         In particular, such mechanisms SHOULD be able to detect
         multicast failure quickly on par with unicast cases.  It needs
         to avoid the cases where multicast has been in failure for a
         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.
BPN=>I don't really understand the above paragraph.

YK=> I see, my idea for next revision is like this.  Please point out if it does not make sense.

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

6.6.  Security

   [...]
   Moreover, because multicast, broadcast, and unknown-unicast need more
   resources than unicast, a SP network MUST have safeguards
   against unwanted or malicious multicast traffic.  This applies to data
   packets.
BPN=>This requirement also applies to unwanted or malicious control packets too.

YK=> You're correct.  This paragraph is aimed to focus on traffic forwarding
(bandwidth)
point, so I'll rephrase "This mainly applies to data packets."

6.8.  L2VPN Wholesale

   A solution MUST allow a situation where one SP is offering L2VPN
   services to another SP.  One example here is a wholesale model where
   one VPLS interconnects other SPs' VPLS or 802.1D network islands.
   For customer SP, their multicast transport can obtain enhancement by
   virtue of multicast VPLS in the wholesaler SP. 
BPN=>I don't understand this sentence.

YK=> What about this?
      For customer SP, their multicast forwarding can be optimized by
      making use of multicast VPLS in the wholesaler SP. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Saturday, August 19, 2006 12:09 AM
> To: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-l2vpn-vpls-mcast-reqts-02.txt
> 
> Colleagues,
> 
> Please find attached my review of draft-ietf-l2vpn-vpls-mcast-reqs-02.
> 
> It is mostly editorial corrections/changes but there are some 
> more general comments too and I have highlighted a number of 
> sections of text that I do not understand.
> 
> Thanks
> Ben
> 
> --
> Ben Niven-Jenkins
> Network Architect, BT Exact
>   
> E-mail: [email-masked]
> Office: +44 (0)1473 648225
> Mobile: +44 (0)7918 077205
>    Fax: +44 (0)1332 578827
> [email-masked] <mailto:[email-masked]> wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > This draft is a work item of the Layer 2 Virtual Private Networks 
> > Working Group of the IETF.
> > 
> > 	Title		: Requirements for Multicast Support in
> > Virtual Private LAN Services
> > 	Author(s)	: Y. Kamite, et al.
> > 	Filename	: draft-ietf-l2vpn-vpls-mcast-reqts-02.txt
> Pages		: 28
> > 	Date		: 2006-6-26
> > 
> > This document provides functional requirements for network solutions
> >    that support multicast over Virtual Private LAN Service 
> (VPLS).  It
> >    specifies requirements both from the end user and 
> service provider
> >    standpoints.  It is intended that potential solutions will use 
> > these
> >    requirements as guidelines.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mcas
> > t-reqts-02.txt
> > 
> > To remove yourself from the I-D Announcement list, send a 
> message to 
> > [email-masked] with the word unsubscribe in 
> the body of 
> > the message.
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> > 
> > 
> > Internet-Drafts are also available by anonymous FTP. Login with the 
> > username "anonymous" and a password of your e-mail address. After 
> > logging in, type "cd internet-drafts" and then
> > 	"get draft-ietf-l2vpn-vpls-mcast-reqts-02.txt".
> > 
> > A list of Internet-Drafts directories can be found in 
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > 	[email-masked].
> > In the body type:
> > 	"FILE
> > /internet-drafts/draft-ietf-l2vpn-vpls-mcast-reqts-02.txt".
> > 
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> > 
> > 
> > Below is the data which will enable a MIME compliant mail reader 
> > implementation to automatically retrieve the ASCII version of the 
> > Internet-Draft.
> 
>

---

From: <[email-masked]>
Date: Tue, 12 Sep 2006 14:30:31 +0100

Yuji,

Please see inline.  I've snipped the parts that aren't relevant.

>       Layer-2 multicast domain can be the same as the Layer-2
>       broadcast domain (i.e., VLAN), but it can be smaller than that
> with       additional control. BPN=>The above definition is poorly
> written.  I understand 
> what it is trying to say but the English isn't clear.
> 
> YK=> Do you have any suggestions?  I thought the current

How about something like:

"Multicast domain: an area in which multicast data is transmitted.  In
this document, this term has a generic meaning which can refer to
Layer-2 and Layer-3.  Generally, the Layer-3 multicast domain is
determined by the Layer-3 multicast protocol used to establish
reachability between all potential receivers in the corresponding
domain.  The Layer-2 multicast domain can be the same as the Layer-2
broadcast domain (i.e., VLAN), but it may be restricted to being smaller
than the Layer-2 broadcast domain if an additional control protocol is
used."

> YK=> I'll change 'them'into 'mutlicast data traffic'.

That's fine. (but multicast not mutlicast) :-)

>       access/metro network to deliver multicast traffic in an
>       efficient way.
> BPN=>The above paragraph doesn't read very well.  Suggest
> something like "SPs might expect VPLS as an access/metro
> network to deliver multicast traffic (such as Triple-play
> (Video, Voice, Data) and Multicast IP VPNs) in an efficient way.
> 

OK

>      [snip]
>       also simplicity.  Generally speaking, there is a
> trade-off between efficiency and simplicity

OK.  How about something like "Generally speaking, there is a trade-off
between efficiency and simplicity in terms of bandwidth usage and state
maintenance, so the optimum trade-off will vary depending on the
requirements of each IP service provider."

>    characteristic are quite different from multicast/broadcast.

OK.  Would suggest replacing 'needs' with 'requires' and
'characteristic' with 'characteristics'.

>       necessary, but any information irrelevant to multicast transport

OK.

> YK=> I'll change it into "with the goal of limiting flooding scope. "

OK.

>     A solution SHOULD provide these parameters with Ethernet
> multicast     group level granularity. 

OK.

>      multicast traffic fail concurrently.

OK but 'mutlicast' should be 'multicast'.

> BPN=>Doesn't this conflict with the requirement in 5.5.1 that
> multicast should not impact unicast fordwarding?
> 
>      on either side, throughput etc. should be provided with
>      appropriate isolation between unicast and multicast.

OK.

> 6.1 Scalability
> 
>    However, a multicast VPLS needs additional scalability
>    considerations related to its expected enhanced mechanisms. 
> [RFC3809] 
> lists common

OK.

>    possible and providing automatic configuration and discovery
> SHOULD    be prioritized. BPN=>I don't understand the paragraph above.
> 
> YK=> Let me change:

OK.

>      traffic is chosen based on PIM/IGMP signaling, static or
>      something. I think you will need to check the statistics of the
> usage of MDTunnels.
> 

OK.

>          multicast failure quickly on par with unicast cases.  It
>          needs to avoid the cases where multicast has been in failure
>          for a 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. 

This is much clearer, thanks.  One minor change "also should" => "should
also".

> point, so I'll rephrase "This mainly applies to data packets."

I haven't read the document since I reviewed it, but is there a
requirement in it that states a SP MUST have safeguards against unwanted
or malicious multicast control traffic.  We (BT) have such a
requirement.  So if you would like to keep this requirement focussed on
traffic forwarding then there needs to be a separate requirement
addressing multicast control traffic.  Otherwise I would suggest making
this requirement address both and rewording it as follows:

"Moreover, because multicast, broadcast, and unknown-unicast need more
resources than unicast, a SP network MUST have safeguards against
unwanted or malicious multicast traffic.  This applies to both multicast
data packets and multicast control packets."

>       making use of multicast VPLS in the wholesaler SP.

OK.

Ben