[multrans] Some comments on draft-jaclee-behave-v4v6-mcast-ps-01

Stig Venaas <stig@venaas.com> Thu, 05 May 2011 21:48 UTC

Return-Path: <stig@venaas.com>
X-Original-To: multrans@ietfa.amsl.com
Delivered-To: multrans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F10E08A7 for <multrans@ietfa.amsl.com>; Thu, 5 May 2011 14:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.191
X-Spam-Level:
X-Spam-Status: No, score=-102.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fI+EEVjkqU2p for <multrans@ietfa.amsl.com>; Thu, 5 May 2011 14:48:54 -0700 (PDT)
Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id D8FC9E07FE for <multrans@ietf.org>; Thu, 5 May 2011 14:48:53 -0700 (PDT)
Received: from [10.33.12.67] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 9CD3F7FE2 for <multrans@ietf.org>; Thu, 5 May 2011 23:48:52 +0200 (CEST)
Message-ID: <4DC31B3C.4050703@venaas.com>
Date: Thu, 05 May 2011 14:48:44 -0700
From: Stig Venaas <stig@venaas.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: multrans@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [multrans] Some comments on draft-jaclee-behave-v4v6-mcast-ps-01
X-BeenThere: multrans@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss the work of IPv4-IPv6 multicast." <multrans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multrans>, <mailto:multrans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multrans>
List-Post: <mailto:multrans@ietf.org>
List-Help: <mailto:multrans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multrans>, <mailto:multrans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 May 2011 21:48:54 -0000

Hi

I've read through this draft again and I have some comments.

First is the scope of the draft. Based on the title it seems
generic, but it seems to focus on a single provider, providing
multicast streams to its users? What if there are multiple
sources, or the users can also send. One example would be
RTCP, another multi-party conferencing. There may be more.

I think you either should make it clearer that this is the
scope, or try to make it more generic. I agree that what you
cover is probably the most common case though.

When you list the issue of AMT, I think you should note that
you lose the benefit of multicast between gateways and relays.
It's just unicast then.

In 3.4.1 it says:

    The content will be delivered once which is better utilized the
    network bandwidth.  However if the application relies on the IP
    information stored in the payload (e.g., SDP), then translation will
    break the application.

This is not obvious. E.g. the source of the SDP may be able to
include both IPv4 and IPv6 and groups, in the case it knows the
translation mappings. You are saying something like this in 4.2 too.

You generally seem to focus a lot on DS-Lite, but there may be other
alternatives. E.g. in 3.4.2. Maybe talk about tunneling in more general
terms, but note that DS-Lite is an example.

In 4.2, you first say that an ALG is needed. But as you explain
yourself, it can also be avoided.

Stig