[MBONED] Comments on draft-ietf-mboned-v4v6-mcast-ps-02

[Alain Durand <[e-mail]>]

Dear wg,

Here are comments on draft-ietf-mboned-v4v6-mcast-ps-02

Alain.


1. Introduction


   The rarefaction of global IPv4 addresses may indeed affect the
   multicast delivery of IPv4-formatted contents to IPv4 receivers.  For
   example, the observed evolution of ADSL broadband access
   infrastructures from a service-specific, multi-PVC (Permanent Virtual
   Circuit) scheme towards a "service-agnostic", single PVC scheme,
   assumes the allocation of a globally unique IPv4 address on the WAN
   (Wide Area Network) interface of the CPE (Customer Premises
   Equipment), or to a mobile terminal), whatever the number and the
   nature of the services the customer has subscribed to.


==> In many cases, multicast is used solely for IP-TV class solutions and its scope is limited to the service provider network.
        Hence, global IPv4 addresses on the CPE are not necessary, private IPv4 addresses can be used to deliver this service.


  Likewise, the global IPv4 address depletion encourages the
   development of IPv6 receivers while contents may very well remain
   IPv4-formatted

==> I do not understand what IPv4 formatted means. Does it mean sourced by an IPv4-only application? If so, say it.


   o  The current design of some multicast-based services like TV
      broadcasting often relies upon the use of a private IPv4
      addressing scheme because of a walled garden approach.  Privately-
      addressed IGMP [RFC2236][RFC3376] traffic sent by IPv4 receivers
      is generally forwarded over a specific (e.g., "IPTV") PVC towards
      an IGMP Querier located in the access infrastructure, e.g., in
      some deployments it is hosted by a BRAS (BRoadband Access Server)
      device that is the PPP (Point-to-Point Protocol) session endpoint
      and which may also act as a PIM DR (Protocol Independent Multicast
      Designated Router)[RFC4601].  This design does not suffer from
      global IPv4 address depletion by definition (since multicast
      traffic relies upon the use of a private IPv4 addressing scheme),
      but it is inconsistent with migrating the access infrastructure
      towards a publicly-addressed single PVC design scheme.


==> This is somehow echoing the point I made earlier: technically, you can
        do this with private IPv4 addresses. If you choose not too for other reasons,
        this is another story.  So this all section should be rewritten to explain
        that the problem statement ONLY applies to cases where the ISP has decided
        for whatever reasons to NOT deploy private IPv4 addresses.


   o  Likewise, other deployments (e.g., cable operators' environments)
      rely upon the public CPE's address for multicast delivery and will
      therefore suffer from IPv4 address depletion

==> I don't understand this statement.



==> KEY POINT: the underlying assumption in that introduction is that the access network will be IPv6-only.
        I'm OK with that assumption, but it needs to be stated clearly as there are other ways to deal with
        IPv4 address exhaustion (for example private IPv4 + CGN, with or without IPv6), for which the rest of
       document may or may not apply.



2.2.  Service Requirements

o  Optimize bandwidth.  Contents should not be multicast twice (i.e.,
      using both versions of IP) to optimize bandwidth usage.  Injecting
      multicast content using both IPv4 and IPv6 raises some
      dimensioning issues that should be carefully evaluated by service
      providers during network planning operations.  For instance, if
      only few IPv6-enabled receivers are in use, it can be more
      convenient to convey multicast traffic over IPv4 rather than
      doubling the consumed resources for few users.  IPv4/IPv6 co-
      existence solutions should be designed to optimize network
      resource utilization.

==> CRITICAL: If I follow the logic here and I make the assumption that IPv4-only receivers will NEVER go away,
        them we are stuck forever using IPv4 multicast on the last mile!!!

        This is a VERY serious issue here, and I consider it a show stopper, unless there is a way to
        completely segregate CPEs that are multicast IPv6 capable and put them into a completely different
        infrastructure than those who are not. Even if you were to use a single vlan per subscriber,
        can you guarantee that you know exactly if that subscriber CPE is multicast IPv6 capable or not?
        Maybe you can in some environments and not in others.

        Further more, if you have a mix of multicast v6 subscriber and multicast v4 subscriber, what do you want
        to use as a protocol on the edge network? Are you OK to double the bandwidth there or not?
        This is the CORE issue the document should expand on, explaining when and where it is OK
        to send both v4 multicast and v6 multicast and where it is not. Text like "content should not be multicast twice"
        is nice and well, but feels a bit like hand waving.