Re: [MIPSHOP-MIH-DT] draft-ietf-mipshop-mstp-solution-02.txt

Vijay Devarapalli <vijay.devarapalli@azairenet.com> Fri, 11 April 2008 15:23 UTC

Return-Path: <mipshop-mih-dt-bounces@ietf.org>
X-Original-To: mipshop-mih-dt-archive@optimus.ietf.org
Delivered-To: ietfarch-mipshop-mih-dt-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE203A6ACA; Fri, 11 Apr 2008 08:23:40 -0700 (PDT)
X-Original-To: mipshop-mih-dt@core3.amsl.com
Delivered-To: mipshop-mih-dt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 308CC3A6ACA for <mipshop-mih-dt@core3.amsl.com>; Fri, 11 Apr 2008 08:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 tR7XSdsYp6mJ for <mipshop-mih-dt@core3.amsl.com>; Fri, 11 Apr 2008 08:23:38 -0700 (PDT)
Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 387783A6C07 for <mipshop-mih-dt@ietf.org>; Fri, 11 Apr 2008 08:23:38 -0700 (PDT)
Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Apr 2008 08:24:01 -0700
Message-ID: <47FF8287.4060902@azairenet.com>
Date: Fri, 11 Apr 2008 08:23:51 -0700
From: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: "Telemaco Melia (tmelia)" <tmelia@cisco.com>
References: <DD0238A0AAE9B74A8F70A91BDF497C2F0380108B@xmb-ams-335.emea.cisco.com> <E5E76343C87BB34ABC6C3FDF3B31272702336AC5@daebe103.NOE.Nokia.com> <DD0238A0AAE9B74A8F70A91BDF497C2F03857F5C@xmb-ams-335.emea.cisco.com>
In-Reply-To: <DD0238A0AAE9B74A8F70A91BDF497C2F03857F5C@xmb-ams-335.emea.cisco.com>
X-OriginalArrivalTime: 11 Apr 2008 15:24:01.0790 (UTC) FILETIME=[121149E0:01C89BE8]
Cc: mipshop-mih-dt@ietf.org
Subject: Re: [MIPSHOP-MIH-DT] draft-ietf-mipshop-mstp-solution-02.txt
X-BeenThere: mipshop-mih-dt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MIPSHOP Media Independent Handover Design Team List <mipshop-mih-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mipshop-mih-dt>, <mailto:mipshop-mih-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mipshop-mih-dt>
List-Post: <mailto:mipshop-mih-dt@ietf.org>
List-Help: <mailto:mipshop-mih-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mipshop-mih-dt>, <mailto:mipshop-mih-dt-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mipshop-mih-dt-bounces@ietf.org
Errors-To: mipshop-mih-dt-bounces@ietf.org

Hi Tele,

I assume you are talking about the following paragraph.

>    This section assumes the use of IPv6 and DHCPv6 based mechanisms to
>    discover MoS services in home while the MN is in visited network.  If
>    similar functionalities are desired for IPv4 additional DHCPv4
>    extensions would be required.  Since use cases requiring these
>    extensions were not identified at the time of writing this document,
>    they were excluded from the scope of the document.

A simple question. Why is IPv6 assumed? A MOS should be
reachable when its address is IPv4 or IPv6. The mobile node
MUST be able to reach the MOS server whether it is on an IPv4
or IPv6 access network. Correct?

What is the point of discovering the IPv6 address of the MOS,
when the mobile node is on an IPv4 access network? For Mobile
IPv6 bootstrapping mechanisms we assume that the mobile node
needs to discover the IPv4 address of the home agent when it
is on an IPv4 access network.

I must be missing something.

Vijay

Telemaco Melia (tmelia) wrote:
> Gabor, all,
>  
> I updated the text according to your suggestions (slightly modified 
> though). Doc is attached.
>  
> I have been spending some time checking what would be the required 
> changes to delete the remark added at the end of section 5.3.
> I would like to know what Vijay and Stefano think about the issue. Do 
> you see use cases requiring an update to the specs?
> If yes, please let us know as soon as possible so we can update all the 
> docs.
> If not then we can post version -02 and boost the discussion around the 
> adoption of new documents. 
>  
> thanks
> tele
>  
> ------------------------------------------------------------------------
> *From:* Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]
> *Sent:* Thursday, April 10, 2008 12:15 AM
> *To:* Telemaco Melia (tmelia); mipshop-mih-dt@ietf.org
> *Subject:* RE: [MIPSHOP-MIH-DT] draft-ietf-mipshop-mstp-solution-02.txt
> 
> Hi Tele,
>  
> to the comment in 5.2 lets add this note (after the previous paragraph, 
> ending ' ... DNS query')
>  
> 
> When the discovery of an MoS at the visited network, using the FQDN 
> returned in the reverse DNS query, is not successful, the MN MAY attempt 
> to remove portions from the left side of the FQDN and attempt discovery 
> again. The process MAY be repeated iteratively until a successful discovery.
> 
> section 5.4:
> 
> modify this sentence: "If the  MN does not yet know the domain name of 
> the network, learning it may
>    require more than one operation, as pre-configuration and DHCP
>    methods can not be used."
> 
> to: "If the  MN does not yet know the domain name of the network, 
> learning it may
>    require more than one operation, as  DHCP based discovery can not be 
> used and pre-configuration is not a feasible solution in case of an 
> arbitrary remote network."
> 
> regarding the comment in 5.3: rfc4004 does not specify how the discovery 
> of an MoS could be done, it doesn't have a general purpose container. 
> One would need to define an extension to 4004 to be able to fetch eg a 
> preconfigured MoS address from the AAA (it could even be part of 
> draft-stupar-mos-diameter-options). I would reformulate it to this:
> 
> This section assumes the use of IPv6 or MIPv6 and DHCPv6 based
>    mechanisms to discover MoS services in home while the MN is in
>    visited network. If similar functionalities are desired for IPv4 or 
> MIPv4 and DHCPv4, additional AAA and DHCPv4 extensions would be 
> required. Since use cases requiring these extensions were not identified 
> at  the time of writing this document, they were excluded from the scope 
> of the document.
> 
> Vijay has left azairnet and his email address doesn't work any longer. 
> An implicit question is if he will continue with his mipshop chair tasks 
> or not. It may have an impact on these documents.
> 
> - Gabor
> 
> 
>     ------------------------------------------------------------------------
>     *From:* mipshop-mih-dt-bounces@ietf.org
>     [mailto:mipshop-mih-dt-bounces@ietf.org] *On Behalf Of *ext Telemaco
>     Melia (tmelia)
>     *Sent:* Monday, April 07, 2008 9:48 AM
>     *To:* mipshop-mih-dt@ietf.org
>     *Subject:* [MIPSHOP-MIH-DT] draft-ietf-mipshop-mstp-solution-02.txt
> 
>     Hi guys,
>      
>     Here is the revised version. All editorial comments have been
>     hopefully digested.
>     There are only a couple of open points, you can track them looking
>     for [COMMENT].
>     One is for Gabor, the second one is about the use of DHCPv4 to
>     discover MoS in visited networks only. Your opinion is welcome.
>      
>     Please go through the document and let me know anything else missing.
>      
>     Thanks
>     Tele
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> MIPSHOP-MIH-DT mailing list
> MIPSHOP-MIH-DT@ietf.org
> https://www.ietf.org/mailman/listinfo/mipshop-mih-dt

_______________________________________________
MIPSHOP-MIH-DT mailing list
MIPSHOP-MIH-DT@ietf.org
https://www.ietf.org/mailman/listinfo/mipshop-mih-dt