[BEHAVE] Comments on draft-venaas-behave-v4v6mc-framework-00.txt
Dave Thaler <dthaler@microsoft.com> Tue, 21 July 2009 23:00 UTC
Return-Path: <dthaler@microsoft.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE6393A6892 for <behave@core3.amsl.com>; Tue, 21 Jul 2009 16:00:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m32L2ecgooHb for <behave@core3.amsl.com>; Tue, 21 Jul 2009 16:00:45 -0700 (PDT)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 368813A688F for <behave@ietf.org>; Tue, 21 Jul 2009 16:00:45 -0700 (PDT)
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Tue, 21 Jul 2009 16:00:43 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server id 14.0.621.7; Tue, 21 Jul 2009 16:00:43 -0700
Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.215]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Tue, 21 Jul 2009 16:00:44 -0700
From: Dave Thaler <dthaler@microsoft.com>
To: "stig@cisco.com" <stig@cisco.com>
Thread-Topic: Comments on draft-venaas-behave-v4v6mc-framework-00.txt
Thread-Index: AcoKVw2q2vHs8ntWRQuSVeuwo/VSPw==
Date: Tue, 21 Jul 2009 23:00:34 +0000
Message-ID: <E4561B14EE2A3E4E9D478EBFB5416E1B12654C@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/mixed; boundary="_004_E4561B14EE2A3E4E9D478EBFB5416E1B12654CTK5EX14MBXW651win_"
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 21 Jul 2009 16:10:26 -0700
Cc: Behave WG <behave@ietf.org>
Subject: [BEHAVE] Comments on draft-venaas-behave-v4v6mc-framework-00.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jul 2009 23:00:46 -0000
Attached is a marked up copy with my full comments. Some high level points/questions: 1) Is there anything special you could do with certain types of IPv6 addresses such as Unicast-Prefix-Based Multicast addresses (RFC 3306), Embedded-RP addresses, or link-scoped RFC 4489, to allow a simple stateless translation for scenarios that would otherwise be hard? 2) Make sure you consider the case of multiple parallel translators (especially if they're stateless ones). For example, switching to SPT may go through a different translator in this case. 3) Having logic be application-independent whenever possible is a good thing. You finally mention this at the end of 3.2, but until then the draft seems to assume application changes. 4) Don't forget the cases where there's no middlebox, such as an IPv4-only app on a dual-stack node wanting to join a group sourced on the same link. These are generally scenarios for in-host translation. -Dave