Re: [netext] draft-ietf-netext-pmipv6-flowmob-04

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Tue, 18 September 2012 17:45 UTC

Return-Path: <cjbc@it.uc3m.es>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F324B21E8043 for <netext@ietfa.amsl.com>; Tue, 18 Sep 2012 10:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level:
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 7UA5TmX7L8KZ for <netext@ietfa.amsl.com>; Tue, 18 Sep 2012 10:45:57 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id EF53221F851C for <netext@ietf.org>; Tue, 18 Sep 2012 10:45:56 -0700 (PDT)
X-uc3m-safe: yes
Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 732A7CAE9A2; Tue, 18 Sep 2012 19:45:52 +0200 (CEST)
Message-ID: <1347990352.18353.115.camel@acorde.it.uc3m.es>
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: sarikaya@ieee.org
Date: Tue, 18 Sep 2012 19:45:52 +0200
In-Reply-To: <CAC8QAcegrZifKxbQ=wn4hEZYXutGLPg6Mtmqxd6=edioiT53Qg@mail.gmail.com>
References: <CAC8QAcegrZifKxbQ=wn4hEZYXutGLPg6Mtmqxd6=edioiT53Qg@mail.gmail.com>
Organization: Universidad Carlos III de Madrid
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-n11MisSI5k/vJAHNqw0v"
X-Mailer: Evolution 3.4.3-1
Mime-Version: 1.0
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19192.000
X-TM-AS-Result: No--9.403-7.0-31-1
X-imss-scan-details: No--9.403-7.0-31-1
Cc: netext@ietf.org
Subject: Re: [netext] draft-ietf-netext-pmipv6-flowmob-04
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: cjbc@it.uc3m.es
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Sep 2012 17:45:58 -0000

Ni Behcet, all,

Again, apologies for the late reply.

Thanks for your comments and questions. Please find some comments inline
below.

On Fri, 2012-08-24 at 16:13 -0500, Behcet Sarikaya wrote:
> Hi Carlos,
> 
> I have questions on Section 3.2.1. on MN sharing a common set of
> prefixes on all MAGs.
> 
> I don't understand why this is related to flow mobility but not prefix
> allocation policy.
> In Fig. 2, you consider flow Y to pref1::mn1 on if2
> 
> and then you move flow Y to if1. I am confused about the figure. How
> come pref1::mn1 and pref1::mn1 stays the same? What is mn1? Is it the
> iid?

mn1 are the 128-N rightmost bits of the MN1 address, where N is the
prefix length. Typically mn1 would correspond to the iid.

> Do you assume that both if1 and if2 have the same iid? How could this
> be possible? Secondly you did not mention this assumption.

The document does not go into the details of whether if1 and if2 have
the same iid or not. The assumptions on the MN side are the following:

  "It is
   assumed that the mobile node IP layer interface can simultaneously
   and/or sequentially attach to multiple MAGs, possibly over multiple
   media.  One form to achieve this multiple attachment is described in
   [I-D.ietf-netext-logical-interface-support], which allows the mobile
   node supporting traffic flows on different physical interfaces
   regardless of the assigned prefixes on those physical interfaces."

You can also check Section 6 on MN considerations.

> 
> I think that if2 should be referred to as mn2 then the situation will
> be clear, i.e. moving flows between two different interfaces with
> different addresses, so this case is not any different than the cases
> you have in Sections 3.2.2 and 3.2.3.

The point is to address (in Section 3.2.1) a different scenario in which
the same prefix (or set of prefixes) is assigned to different physical
interfaces. This is possible, so it should be considered.

> 
> You  explain in this section that some flow mobility update action (?)
> happens in both LMA and MN and the flow is magically moved. Even if we
> assume what you have is correct this case does not deserve any mention
> in the draft, i.e. there is no observable action to specify.

It is needed to specify how to ensure that different physical interfaces
of the same MN get assigned the same prefix (or set of prefixes).

Thanks again for your comments,

Carlos

> 
> I have more coming up later.
> 
> Regards,
> 
> Behcet
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext

-- 
Carlos Jesús Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67