Re: [savi] AD review of draft-ietf-savi-framework

marcelo bagnulo braun <marcelo@it.uc3m.es> Fri, 27 May 2011 07:20 UTC

Return-Path: <marcelo@it.uc3m.es>
X-Original-To: savi@ietfa.amsl.com
Delivered-To: savi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F90E078E for <savi@ietfa.amsl.com>; Fri, 27 May 2011 00:20:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 PKRWffZw89JX for <savi@ietfa.amsl.com>; Fri, 27 May 2011 00:20:39 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 83128E0785 for <savi@ietf.org>; Fri, 27 May 2011 00:20:37 -0700 (PDT)
X-uc3m-safe: yes
Received: from marcelo-bagnulos-macbook-pro-2.local (216.219-78-194.adsl-static.isp.belgacom.be [194.78.219.216]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 75BEC6FA8CF for <savi@ietf.org>; Fri, 27 May 2011 09:20:31 +0200 (CEST)
Message-ID: <4DDF50BD.7080301@it.uc3m.es>
Date: Fri, 27 May 2011 09:20:29 +0200
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: savi@ietf.org
References: <4DDC19D4.2040104@piuha.net> <634BEF66B2B74684B180B35F2C94BCEB@junbiVAIOz138>
In-Reply-To: <634BEF66B2B74684B180B35F2C94BCEB@junbiVAIOz138>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-18162.003
Subject: Re: [savi] AD review of draft-ietf-savi-framework
X-BeenThere: savi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list for the SAVI working group at IETF <savi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/savi>, <mailto:savi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/savi>
List-Post: <mailto:savi@ietf.org>
List-Help: <mailto:savi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/savi>, <mailto:savi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 May 2011 07:20:40 -0000

one reply


El 25/05/11 3:46, Jun Bi escribió:
>
>> configuration method, in addition to the variant that handles all IP
>> address assignment methods, is to minimize the complexity of the
>> common case:  many link deployments today either are constrained to a
>> single IP address assignment methods or, equivalently from the
>> perspective of the SAVI method, separate IP address assignment
>> methods into different IP address prefixes.  The SAVI method for such
>> links can be simpler than the SAVI method for links with multiple IP
>> address assignment methods per IP address prefix.
>>
> The reason to develop SAVI method variants for each single IP address
>
> Hmm. I'm not sure I buy this. First of all, I would claim that many
> links support multiple address assignment methods. For instance, dual
> stack links typically today support SLAAC for IPv6 and DHCP for IPv4.
> And its obvious that to fly in the IETF, the SAVI solution needs to
> support multiple methods. I would just replace the above text with:
>

The difficult case here is when different methods are used to assign 
addresses _from the same prefix_
This case is complicated because different methods can assign the same 
address and SAVI needs to be able to determine which is the winning method.
So, while i agree with you that it is fairly common the case where 
multiple address assignment methods are used in a given link, i believe 
that the case where multiple address assignement methods assign 
addresses from the same prefix is much less common.

I guess we need to make the distinction clearer in the document.

Regards, marcelo