Re: [netext] draft-ietf-netext-pmipv6-flowmob-04 Section 3.2.2
Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Mon, 08 October 2012 07:28 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 084C121F8777 for <netext@ietfa.amsl.com>; Mon, 8 Oct 2012 00:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.537
X-Spam-Level:
X-Spam-Status: No, score=-4.537 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_20=-0.74, 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 X10Nqn5BIGOQ for <netext@ietfa.amsl.com>; Mon, 8 Oct 2012 00:28:56 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id C15F921F8767 for <netext@ietf.org>; Mon, 8 Oct 2012 00:28:55 -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@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id ACDE776B64D; Mon, 8 Oct 2012 09:28:54 +0200 (CEST)
Message-ID: <1349681334.4721.27.camel@acorde.it.uc3m.es>
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: sarikaya@ieee.org
Date: Mon, 08 Oct 2012 09:28:54 +0200
In-Reply-To: <CAC8QAcfbELLM7ReKHSWTW_QCSemfHuZxsXh=5mkACd6SPYhHWg@mail.gmail.com>
References: <CAC8QAcfbELLM7ReKHSWTW_QCSemfHuZxsXh=5mkACd6SPYhHWg@mail.gmail.com>
Organization: Universidad Carlos III de Madrid
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-iYyuiuWb0GKAtk38AE1y"
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-19252.005
X-TM-AS-Result: No--17.159-7.0-31-1
X-imss-scan-details: No--17.159-7.0-31-1
Cc: netext@ietf.org
Subject: Re: [netext] draft-ietf-netext-pmipv6-flowmob-04 Section 3.2.2
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: Mon, 08 Oct 2012 07:28:57 -0000
Hi Behcet, Thanks for the comments. Please, see below. On Mon, 2012-10-01 at 16:21 -0500, Behcet Sarikaya wrote: > Hi Carlos, > I am unabe to understand this sentence at the beginning of Sec. 3.2.2 > (as we discussed in the previous thread): > > A different flow mobility scenario happens when the local mobility > anchor assigns different sets of prefixes to physical interfaces of > the same mobile node. I think I covered this in my other e-mail. > > Again, this statement: > > Since the local mobility anchor cannot send a PBA message > which has not been triggered in response to a received PBU message, > new signaling messages are defined to cover this case. > > Why not structure it in two sections: LMA Initiated Flow Mobility > where you need to define new signaling and > MAG Initiated Flow Mobility where existing PBU/PBA exchange can be used? The draft does not make any assumption on who initiates flow mobility, but just defines protocol changes to make it happen. This was long time ago discussed and the draft reflects the consensus. Nobody complained about current structure. > > For LMA Initiated case, why do you think Flow Identification Mobility > option initiated by MN would be sufficient? Shouldn't LMA be able to > do more things? More actions? > > Below on Page 13, you have: > The MAG MAY also include the Flow > Identification Mobility option in the PBU message that it sends to > the LMA. This serves as a request from MAG to LMA to consider the > flow policy rules specified in the option. > > This is basically defining MAG Initiated flow mobility. As I mentioned before, the draft does not assume MAG or LMA initiated mobility, but it is as most generic as possible. > > How would a MAG know that MN has multiple interfaces? This is out of the scope of the document. Thanks, Carlos > > Only LMA can inform MAG about this, please see > draft-sarikaya-netext-flowmob-ext-00 that I posted last week. > > My overall comment is that in Section 3 there is too much emphasis on > the prefix assignment and not enough emphasis on the real protocol > issues. I am not convinced that playing with the way PMIPv6 assigns > HNPs is the solution to flow mobility. > > 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 Sect… Behcet Sarikaya
- Re: [netext] draft-ietf-netext-pmipv6-flowmob-04 … Carlos Jesús Bernardos Cano