Re: [netext] draft-ietf-netext-pmipv6-flowmob-04
Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Thu, 20 September 2012 08:32 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 C61E821F8624 for <netext@ietfa.amsl.com>; Thu, 20 Sep 2012 01:32:44 -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 bLiRRkV8-Yyr for <netext@ietfa.amsl.com>; Thu, 20 Sep 2012 01:32:43 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 946B821F8449 for <netext@ietf.org>; Thu, 20 Sep 2012 01:32:43 -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 AF11DCAE92F; Thu, 20 Sep 2012 10:32:37 +0200 (CEST)
Message-ID: <1348129957.18353.179.camel@acorde.it.uc3m.es>
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: sarikaya@ieee.org
Date: Thu, 20 Sep 2012 10:32:37 +0200
In-Reply-To: <CAC8QAccZPC8sLaoV1xG7hxefCZQn0Cbr4fU=qSPdggbuKpT1QA@mail.gmail.com>
References: <CAC8QAcegrZifKxbQ=wn4hEZYXutGLPg6Mtmqxd6=edioiT53Qg@mail.gmail.com> <1347990352.18353.115.camel@acorde.it.uc3m.es> <CAC8QAccZPC8sLaoV1xG7hxefCZQn0Cbr4fU=qSPdggbuKpT1QA@mail.gmail.com>
Organization: Universidad Carlos III de Madrid
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-VxQ3SArs5BPUYB0xhEIm"
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-19196.000
X-TM-AS-Result: No--22.526-7.0-31-1
X-imss-scan-details: No--22.526-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: Thu, 20 Sep 2012 08:32:45 -0000
Hi Behcet, On Wed, 2012-09-19 at 15:07 -0500, Behcet Sarikaya wrote: > Hi Carlos, > > Please see inline. > > On Tue, Sep 18, 2012 at 12:45 PM, Carlos Jesús Bernardos Cano > <cjbc@it.uc3m.es> wrote: > > 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. > > You did not answer this one. Sorry, I didn't see any question there. If you want me to comment on this, assigning a common set of prefixes is one of the possible ways of enabling flow mobility -- as documented in the draft -- and therefore I see it as related to flow mobility. > > >> 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. > > > > > Can I say that pref1::mn1 can not be the same? > This is based on your reply and the fact that you did not make any > assumption/requirement on this, so you need to modify the figure > accordingly. You mean the iid part of the address not being the same, while the prefixes are? I don't see what would be the value of doing so. If the addresses assigned by distinct MAGs are different, then the other mechanisms described in the draft could be used, but using different prefixes is cleaner, simpler and avoids potential ND-related problems. > > >> > >> 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. > > > > Yes but the problem is not any different than when different prefixes > are assigned, so what is the big deal that requires a different > section which happens to be the first section (3.2.1)? I disagree here. The problem is different, as in one case there is no additional changes required in the MAG routing to be able to forward packets, while in the other there is. The order of the section is not meaningful, there is no special reason for having it first, just that we felt it was easier to describe the solutions in that way. > > >> > >> 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). > > Please see above. If this case is no different than the cases in 3.2.2 > and 3.2.3 then why? But the case is different. Thanks, Carlos > > Regards, > > Behcet -- Carlos Jesús Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67
- [netext] draft-ietf-netext-pmipv6-flowmob-04 Behcet Sarikaya
- Re: [netext] draft-ietf-netext-pmipv6-flowmob-04 Carlos Jesús Bernardos Cano
- Re: [netext] draft-ietf-netext-pmipv6-flowmob-04 Behcet Sarikaya
- Re: [netext] draft-ietf-netext-pmipv6-flowmob-04 Carlos Jesús Bernardos Cano
- Re: [netext] draft-ietf-netext-pmipv6-flowmob-04 Behcet Sarikaya
- Re: [netext] draft-ietf-netext-pmipv6-flowmob-04 Carlos Jesús Bernardos Cano
- Re: [netext] draft-ietf-netext-pmipv6-flowmob-04 Behcet Sarikaya
- Re: [netext] draft-ietf-netext-pmipv6-flowmob-04 Carlos Jesús Bernardos Cano
- Re: [netext] draft-ietf-netext-pmipv6-flowmob-04 Behcet Sarikaya
- Re: [netext] draft-ietf-netext-pmipv6-flowmob-04 Carlos Jesús Bernardos Cano