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

[<[e-mail]>]

Bonjour Alain,

Thanks for the feedback - please see inline.

[snip]

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.
[CJ] This is precisely the point of the above text. Most of IPTV services are currently designed according to a typical private IPv4 address-based walled garden approach, as you rightfully mention. Such environments usually rely upon an IPTV service-specific PVC, while other traffic (internet, voice) is conveyed over different PVCs that remain service-specific. Some operators are moving from this service-specific, multi-PVC design to a service-agnostic, single PVC design, whatever the number and the nature of the services subscribed by the customer. In that case, an RFC1918-based walled garden IPTV service design is hard to deploy, as corresponding customers rarely subscribe to an IPTV service only.


  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.
[CJ] Fair enough.


   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.

[CJ] We cannot restrict the scope of the problem statement to this sole use case, because of the other contexts documented in Section 3.



   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.
[CJ] The CPE is assigned a global IPv4 address. In some environments, this address is used for multicast delivery purposes. As a consequence, global IPv4 address depletion may jeopardize the delivery of such services, but I'll let cable representatives further elaborate.



==> KEY POINT: the underlying assumption in that introduction is that the access network will be IPv6-only.
[CJ] This should indeed be consistent with a global IPv6 strategy that not only relates to Internet services, but also the whole service portfolio of an operator, IPTV services included.
        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.
[CJ] Agreed, but please keep in mind this is a problem statement that tries to illustrate contexts where multicast transition techniques may be worth the investigation (Section 3). As such, what has been documented in this section 3 reflects the situation of some of the operators who have co-authored this draft.



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!!!
[CJ] The assumption you make looks a bit strong to me as current SoA seems to indicate that Dual Stack committed roadmaps are being specified by the STB vendor industry. The point is to make IPv6 the rule, not the exception even in typical IPTV service environments. Admittedly, the hardest part is that current IPTV contents are unlikely to be IPv6 multicast in the short term.

        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.
[CJ] That would be an easy answer for service providers who provide managed CPEs, obviously (and who master the functional evolution of such CPEs). In case a customer wants to use an off-the-shelf CPE, he/she usually has to make sure the said CPE complies with the service specifications published by the provider. And this is clearly not IPTV-specific or multicast-specific.

        Furthermore, 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?
[CJ] The mix you mention can reasonably assume the receivers will be DS-enabled, right? But the answer to your question obviously depends on the "format" of the application (IPv4-only content, DS content) and the service provider's IPv6 strategy, which brings us back to one of your previous points. I know some operators privilege IPv6 as the "transport" protocol, regardless of the nature of the services subscribed by the customer, which, in the case of IPTV for example, would ideally assume IPv6-enabled receivers and, more importantly, IPv6-formatted contents. Unfortunately, we're not at this stage yet. Meaning that for those operators, they either have to (1) stick to a typical walled garden design (possibly at the cost of *also* running out of private IPv4 addresses in a not so distant future (given mobile data growth, for example) or (2) investigate multicast transition techniques, such as the one documented in http://tools.ietf.org/html/draft-ietf-softwire-dslite-multicast-05.
        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.
CJ: In that case, I don't think this is a problem statement document anymore. Besides, this kind of recommendation is likely to be dependent on the service provider environment, given the nature of the multicast service to be delivered, the foreseen business growth as a function of the market coverage, the network capabilities, etc.

Cheers,

Christian.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.