From julien.laganier.ietf@googlemail.com Tue Jun 2 04:21:39 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EA8C3A6CFC for ; Tue, 2 Jun 2009 04:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 z7csQESV1dwq for ; Tue, 2 Jun 2009 04:21:38 -0700 (PDT) Received: from mail-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by core3.amsl.com (Postfix) with ESMTP id 2FEA23A6AF7 for ; Tue, 2 Jun 2009 04:21:37 -0700 (PDT) Received: by bwz22 with SMTP id 22so8070918bwz.37 for ; Tue, 02 Jun 2009 04:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RipSkIVrhkxpvUqorBjHTUgUOv5m86AI4NUUn1s6TcY=; b=VvGDIqC2pjS+PreICmnnFVifekvT2M/evIcpodrL/1x3w+/RrPwX+T4LMu2UpCEYzj Kk0QxiSME7d3tZPKh6peQHCt+8wO3w9PQFmjAFZLjMoCQkPG6Y7yJznNGa/e0hd/ppoE v2ojYnNgXby7p2SgSmGpsP+V7ZHJFH2OsrQG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fauXDU5ifI3se7+QjvkT8BkSaL068ZpIVRoltSkxmegOjeH9ayXzUIvk4zjeK1ch3i aQX7rJfNyze4Gikwx13047MXAFRvCoPIve+DbHDWb82GAp6IYAxg1bOn3xOtC+6FW9ta ZbxRI0c+V6BKtpC9c1cH6IKX7X8Usjw9UgXhg= MIME-Version: 1.0 Received: by 10.204.122.141 with SMTP id l13mr6641416bkr.106.1243941694671; Tue, 02 Jun 2009 04:21:34 -0700 (PDT) In-Reply-To: References: <4A16E743.5010400@wichorus.com> Date: Tue, 2 Jun 2009 13:21:34 +0200 Message-ID: <7ad6d6db0906020421m2f6a9cb6xbff75a8da1b43b54@mail.gmail.com> From: Julien Laganier To: Ahmad Muhanna Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] LMA behavior for HI status unknown (was Re: Binding Revocation almost ready for IESG) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 11:21:39 -0000 Hello Ahmad, I think we'd be better with a new revision. Thanks. --julien On Sat, May 23, 2009 at 2:22 PM, Ahmad Muhanna wrote: > Hi Vijay, > > Regards, > Ahmad > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >> Sent: Friday, May 22, 2009 12:56 PM >> To: Muhanna, Ahmad (RICH1:2H10) >> Cc: mext; Julien Laganier >> Subject: LMA behavior for HI status unknown (was Re: Binding >> Revocation almost ready for IESG) >> >> Hi Ahmad, >> >> I am going to split the emails into two, since we are dealing >> with two issues. >> >> Ahmad Muhanna wrote: >> >> >>>> But what should the MAG behavior be when it receives the >> following >> >>>> trigger? >> >>>> >> >>>> =A05 =A0Inter-MAG Handover - Unknown >> >>>> >> >>> [Ahmad] >> >>> The MAG will reject the BRI with code "MN still attached" >> >> :) I mean, >> >>> the MAG is supposed to check whether the mobile node is >> attached or >> >>> not and based on its finding, it should reply back either >> >> success or >> >>> failure, e.g., "MN still attached". >> >> Ok. >> >> >> >> So what does the LMA do now? The new MAG is saying the MN >> attached to >> >> it and the handoff state is "unknown". The old MAG is >> saying the MN >> >> is still attached? Shouldn't this result in a new mobility session >> >> being setup for the attachment through the new MAG? It won't be >> >> treated as a handover anymore. This probably needs to be explained. >> >> >> > [Ahmad] >> > The LMA does nothing other than what is documented in RFC5213. >> > This is exactly the same case as if the LMA did not receive a >> > de-registration from the previous MAG and the timer >> expired. I do not >> > think it is necessary to add anything, but we could add a pointer to >> > RFC5213 for this specific case when handling the AD comments. >> >> This doesn't make sense. RFC 5213 says if the LMA receives a >> PBU with HI set to "handoff state unknown", it should wait >> for MaxDelayBeforeNewBCEAssign amount of time for a >> deregistration PBU from the old MAG. If there is no such >> deregistration message from the old MAG, it would create a >> new mobility session. >> >> The Binding revocation document suggests that the LMA must >> send a binding revocation message with the trigger set to >> "handoff state unknown". If the MN is still attached, the old >> MAG would reject the binding revocation. Then the LMA would >> proceed with creating a new mobility session. > > [Ahmad] > Where in the revocation draft it said that the LMA must send a BRI with > the trigger set to "handoff state unknown"? > >> >> How can these two be compatible? >> > [Ahmad] > We can debate this offlist, I guess:) > Please see below. > >> IMO, the binding revocation document should say that it is >> updating RFC >> 5213 when it comes to the LMA behavior when it receives a PBU >> with HI set to "handoff state unknown". If the LMA and the >> MAG implement binding revocation, they should follow the >> mechanism described in the binding revocation document rather >> than the one in RFC 5213. > > [Ahmad] > Although, I still believe that these two cases compatible but I agree > with the end result that you are proposing. I see your point when the > LMA support Binding Revocation and at the same time already support > RFC5213, we need to be clear on what the LMA needs to do if it decides > to send a BRI message to the old MAG rather than waits for a > de-registration to come. > > Will come up with some text which address this option, i.e., when the > LMA uses BRI proactively to define if the MN is no longer attached to > the old MAG or not to be able to handle the PBU with HI unknown coming > from the new MAG. > > Do we need a new revision for this or we can add the text during the AD > review and comments? > >> >> Vijay >> > From AMUHANNA@nortel.com Tue Jun 2 04:57:02 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F303A6DE5 for ; Tue, 2 Jun 2009 04:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 af716HxGKewu for ; Tue, 2 Jun 2009 04:57:01 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 736003A67F0 for ; Tue, 2 Jun 2009 04:57:01 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n52Buui12775; Tue, 2 Jun 2009 11:56:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Jun 2009 06:56:45 -0500 Message-ID: In-Reply-To: <7ad6d6db0906020421m2f6a9cb6xbff75a8da1b43b54@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LMA behavior for HI status unknown (was Re: Binding Revocation almost ready for IESG) Thread-Index: AcnjdFkyQx8CvVS9QxeE9a/DOkS3xwABLZpg References: <4A16E743.5010400@wichorus.com> <7ad6d6db0906020421m2f6a9cb6xbff75a8da1b43b54@mail.gmail.com> From: "Ahmad Muhanna" To: "Julien Laganier" Cc: mext Subject: Re: [MEXT] LMA behavior for HI status unknown (was Re: Binding Revocation almost ready for IESG) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 11:57:02 -0000 Hi Julien, Sure, will spin a new revision, hopefully quickly.=20 Regards, Ahmad =20 > -----Original Message----- > From: Julien Laganier [mailto:julien.laganier.ietf@googlemail.com]=20 > Sent: Tuesday, June 02, 2009 6:22 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Vijay Devarapalli; mext > Subject: Re: LMA behavior for HI status unknown (was Re:=20 > Binding Revocation almost ready for IESG) >=20 > Hello Ahmad, >=20 > I think we'd be better with a new revision. >=20 > Thanks. >=20 > --julien >=20 > On Sat, May 23, 2009 at 2:22 PM, Ahmad Muhanna=20 > wrote: > > Hi Vijay, > > > > Regards, > > Ahmad > > > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] > >> Sent: Friday, May 22, 2009 12:56 PM > >> To: Muhanna, Ahmad (RICH1:2H10) > >> Cc: mext; Julien Laganier > >> Subject: LMA behavior for HI status unknown (was Re: Binding=20 > >> Revocation almost ready for IESG) > >> > >> Hi Ahmad, > >> > >> I am going to split the emails into two, since we are dealing with=20 > >> two issues. > >> > >> Ahmad Muhanna wrote: > >> > >> >>>> But what should the MAG behavior be when it receives the > >> following > >> >>>> trigger? > >> >>>> > >> >>>> =A05 =A0Inter-MAG Handover - Unknown > >> >>>> > >> >>> [Ahmad] > >> >>> The MAG will reject the BRI with code "MN still attached" > >> >> :) I mean, > >> >>> the MAG is supposed to check whether the mobile node is > >> attached or > >> >>> not and based on its finding, it should reply back either > >> >> success or > >> >>> failure, e.g., "MN still attached". > >> >> Ok. > >> >> > >> >> So what does the LMA do now? The new MAG is saying the MN > >> attached to > >> >> it and the handoff state is "unknown". The old MAG is > >> saying the MN > >> >> is still attached? Shouldn't this result in a new=20 > mobility session=20 > >> >> being setup for the attachment through the new MAG? It won't be=20 > >> >> treated as a handover anymore. This probably needs to=20 > be explained. > >> >> > >> > [Ahmad] > >> > The LMA does nothing other than what is documented in RFC5213. > >> > This is exactly the same case as if the LMA did not receive a=20 > >> > de-registration from the previous MAG and the timer > >> expired. I do not > >> > think it is necessary to add anything, but we could add=20 > a pointer=20 > >> > to > >> > RFC5213 for this specific case when handling the AD comments. > >> > >> This doesn't make sense. RFC 5213 says if the LMA receives=20 > a PBU with=20 > >> HI set to "handoff state unknown", it should wait for=20 > >> MaxDelayBeforeNewBCEAssign amount of time for a deregistration PBU=20 > >> from the old MAG. If there is no such deregistration=20 > message from the=20 > >> old MAG, it would create a new mobility session. > >> > >> The Binding revocation document suggests that the LMA must send a=20 > >> binding revocation message with the trigger set to "handoff state=20 > >> unknown". If the MN is still attached, the old MAG would=20 > reject the=20 > >> binding revocation. Then the LMA would proceed with creating a new=20 > >> mobility session. > > > > [Ahmad] > > Where in the revocation draft it said that the LMA must send a BRI=20 > > with the trigger set to "handoff state unknown"? > > > >> > >> How can these two be compatible? > >> > > [Ahmad] > > We can debate this offlist, I guess:) > > Please see below. > > > >> IMO, the binding revocation document should say that it is=20 > updating=20 > >> RFC > >> 5213 when it comes to the LMA behavior when it receives a=20 > PBU with HI=20 > >> set to "handoff state unknown". If the LMA and the MAG implement=20 > >> binding revocation, they should follow the mechanism=20 > described in the=20 > >> binding revocation document rather than the one in RFC 5213. > > > > [Ahmad] > > Although, I still believe that these two cases compatible=20 > but I agree=20 > > with the end result that you are proposing. I see your=20 > point when the=20 > > LMA support Binding Revocation and at the same time already support=20 > > RFC5213, we need to be clear on what the LMA needs to do if=20 > it decides=20 > > to send a BRI message to the old MAG rather than waits for a=20 > > de-registration to come. > > > > Will come up with some text which address this option,=20 > i.e., when the=20 > > LMA uses BRI proactively to define if the MN is no longer=20 > attached to=20 > > the old MAG or not to be able to handle the PBU with HI=20 > unknown coming=20 > > from the new MAG. > > > > Do we need a new revision for this or we can add the text=20 > during the=20 > > AD review and comments? > > > >> > >> Vijay > >> > > >=20 From julien.laganier.ietf@googlemail.com Tue Jun 2 05:42:26 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5853A6D18 for ; Tue, 2 Jun 2009 05:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 loefje3rFotj for ; Tue, 2 Jun 2009 05:42:26 -0700 (PDT) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by core3.amsl.com (Postfix) with ESMTP id 9B3A73A6CCF for ; Tue, 2 Jun 2009 05:42:25 -0700 (PDT) Received: by fxm12 with SMTP id 12so6472684fxm.37 for ; Tue, 02 Jun 2009 05:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qeMeAGRCCYIq0CMjytM+hqeZNBDhHu+mmaqCYq3WHVM=; b=drpGfU4OgUW5G1x3zmioMy4UXCissbVqmmxWSduhK1E2VkniQXpb/gt3FMxDHOvpFL ChvTPlSAt2xauXi9qiUTlGNNvkElScLLnDk0vMo/u02vq+CvFBBmYX3f6agXIQ3LZfpl Fjg1Rt7UptrC/7nl5qT/vn7zd5f1S1HqFcelg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Y434JCaZVLhc5HkKXaoiPRx+IT0moBx/6dhFHoy21Cbp/QNhKFqSncrM4y7qwup/Wu yqbMXvyoFEWVzFersON+LyJ1OXEqV/CMJPu/v69sLiDxnGrkng7rsT89S3hJWLoIyanF EyzY7Mo//con2u43lqyUd21EQpyGbD2DKn/wQ= MIME-Version: 1.0 Received: by 10.204.113.132 with SMTP id a4mr6782937bkq.27.1243946543361; Tue, 02 Jun 2009 05:42:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Jun 2009 14:42:23 +0200 Message-ID: <7ad6d6db0906020542s5b29e869i6b13bd8db989bf43@mail.gmail.com> From: Julien Laganier To: Yuri Ismailov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] Important considerations for directionality of flow bindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 12:42:27 -0000 Yuri, On Fri, May 29, 2009 at 9:35 AM, Yuri Ismailov wrote: > Hesham, > > This is nice story and makes some sense for the discssion, however some > details are ommited. In your adventure with the helpdesk, it (the helpdes= k) > is a third party service and thus your conclusions make sence. Think of t= he > situation when superior of a heldesk person will tell him/her to check > access point in some room. Would it be the same reaction? I assume not. B= y > that I mean that if, for example, I'll install home agent in my home > network, I can make it know anything I want about MN, and more intresting= is > that how I will do it, does not=A0require any standardization. In other w= ords, > I'm superior of my HA. I have nothing against being the superior or having one, but I'm a bit lost with the point of the analogy... How do you make your HA know that the address XYZ your MN just SLAAC'd at the starbucks downdown is assigned towards on a 54Mbs WiFi link? Are you driving back to home to configure appropriately your HA while the MN stays at starbucks? > This situation is not unthinkable, I=A0personally believe that this is mu= ch > more efficient way of using HA fnctionality as opposed to big service > providers who will have to fight with scalability and performance. Howeve= r, > one does not exclude another. > > Difference between policies and rules is a convertion step. Is there any > reason to restrict where such convertion takes place? I believe there's a valid reason which is called protocol layering. Rules dealing with choice of a MIPv6 Care-of address do belong to the MIPv6 layer. Policies regarding which access technology to use for a given app/service/etc. do not belong to that layer. > True that a HA does > not know what is going on in the access network, on the other hand HA may > know what is the network condition between HA and correspondent node. Eit= her > of this information is important, if not equally important. Nobody said information X is not important while information Y is. An information is important in a given context. I do not care what's the status of your WiFi card, I care about the status of my card. The point is, the information of what is happening on the links to which the MN is attached is of utmost importance in choosing which care-of address to use because the choice of care-of address in turns implies the choice of a link, and this is most likely a wireless link. On the other hand, choosing a care-of adddress has no impact nor is impacted by the network conditions between the HA and the correspondent node. > BTW, what is the numerical representation of "rough consensus"? I assume = is > when majority is for, is it so? 51% majority is not "rough consensus", this is voting. --julien From pierrick.seite@orange-ftgroup.com Tue Jun 2 07:11:52 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9C8028C226 for ; Tue, 2 Jun 2009 07:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35] 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 OlJOAyq319yy for ; Tue, 2 Jun 2009 07:11:51 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id E6D9628C210 for ; Tue, 2 Jun 2009 07:11:50 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Jun 2009 16:11:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Jun 2009 16:11:48 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462191437@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnffAdoGi/aI6bjOkmHZuHuvPZ68wAFUO+wAP49A8A= References: From: To: , , X-OriginalArrivalTime: 02 Jun 2009 14:11:49.0621 (UTC) FILETIME=[12268250:01C9E38C] Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 14:11:52 -0000 Hi all, Please see inline comment. Regards, Pierrick=20 > ________________________________________ > De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part = de > Yuri Ismailov > Envoy=E9 : vendredi 29 mai 2009 09:35 > =C0 : Hesham Soliman; mext > Objet : Re: [MEXT] Important considerations for directionality of > flowbindings >=20 > Hesham, > This is nice story and makes some sense for the discssion, however = some > details are ommited. In your adventure with the helpdesk, it (the > helpdesk) is a third party service and thus your conclusions make = sence. > Think of the situation when superior of a heldesk person will tell = him/her > to check access point in some room. Would it be the same reaction? I > assume not. By that I mean that if, for example, I'll install home = agent > in my home network, I can make it know anything I want about MN, and = more > intresting is that how I will do it, does not require any = standardization. > In other words, I'm superior of my HA. > This situation is not unthinkable, I personally believe that this is = much > more efficient way of using HA fnctionality as opposed to big service > providers who will have to fight with scalability and performance. > However, one does not exclude another. > Difference between policies and rules is a convertion step. >=20 >=20 The difference between policy and rules is not only a matter of = conversion. A policy, is a static, or quasi-static, set of guidance for = the MN (e.g use access network X for application type A,...) while a = rule update requires to be more dynamic. I mean: eventually a policy = could be updated depending on network condition (e.g if X overloaded, = use access network Y for application type A,...) but a rule reacts on = local triggers (e.g. modification of the radio link quality) with a = shorter period of variation. So, IMHO, there is no requirement for = updating policy on a short period and out-of-band mechanism can be used = (e.g. IEEE 802.21 in push mode,...). My 2 cents... >=20 > Is there any reason to restrict where such convertion takes place? = True > that a HA does not know what is going on in the access network, on the > other hand HA may know what is the network condition between HA and > correspondent node. Either of this information is important, if not > equally important. > It is not really difficult to let an MN to reject rules sent by HA, = which > in my view would be quite natural. This implies that HA must follow = the > rules installed by MN until explicit acceptance has been received from = MN. > Such procedure is very similar to an MN beahviour when initiating new = BU, > where MN is not supposed to send any traffic before BU confirmation. > BTW, what is the numerical representation of "rough consensus"? I = assume > is when majority is for, is it so? > Yuri=20 >=20 >=20 > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf = Of > Hesham Soliman > Sent: Thursday, May 28, 2009 12:07 PM > To: mext > Subject: [MEXT] Important considerations for directionality of flow > bindings >=20 > Hi all, >=20 > I've always been a fan of the IETF's tradition of rough concensus (as > opposed to voting). To me, this implies that you need to get your = point > across and get other people to see that point of view. As opposed to > other organisations that require their members to vote and end up with > rigid political positions. >=20 > The chairs asked us about the directionality question of the flows > bindings. > On the charter question, I said that the charter doesn't need to = mention > how a solution should work, but rather what problem needs to be = solved. > Hence, as far as the charter is concerned, I'm fine with transferring > rules "between" the MN and HA without mentioning directions. >=20 > Nevertheless, we still need to agree on identifying the requirement = for > the solution. And when it comes to this, I'm strongly against voting = and > I'll practice this by explaining in this email why I think rules can = not > be transferred from the HA to the MN and that the only direction that > makes sense in MIP is MN->HA. I'll deliberately ignore arguments like > "some people want this" or "an SDO wants this". They fall under the > "meaningless words" > category and I'm incapable of discussing them because they come with > voting attitudes. They all need to be justified if the WG wants to = have > a technical _discussion_. >=20 > Here are my reasons: >=20 > 1. The HA does not know whether a CoA is tied to a certain access > technology. It is one thing for the HA to send a message saying = "forward > port 80 traffic on a wifi link" (a policy) and a completely different > thing to say "forward port 80 traffic using CoA 3ffe::1" (a rule). >=20 > 2. You might argue that the HA can be told by the MN that 3ffe::1 is > tied to a wifi access, so what's the problem now? The problem is that > the HA has no idea about dynamic changes on that wifi link. It doesn't > know if it's congested, it doesn't know what application is using port > 80 (it doesn't have to be web traffic) or port 8000 for that matter = and > doesn't even know if the AP of that wifi link works at all. Finally, = it > doesn't know the user's policies or other admin policies for that MN. > This type of information needs to be sent regularly because it changes > all the time and requires serious cross layer integration including > sometimes layer 8 integration! It's completely impractical. >=20 > 3. If the HA installed rules in the MN, what happens if the MN wants = to > change those rules. Say the wifi link went down, or the MN's wifi > interface went down and it wants to move that traffic to another > interface. Would the HA reject such move? Does the MN have to justify = to > the HA why it needs to move traffic? Does that involve writing a = letter > perhaps? > If you say "well in that case, the HA should let the MN move the > traffic" > then I'll ask you: what's the point of having the HA install this = stuff > if it has no authority and how does it know the reason for the MN's > movement of the flow? > The way to control how users do things is to incentivise them with > charging models and show them that things work better on certain > technologies, not by installing rules that can't be followed. It's a > broken mindset and we've known that it's broken for a long time. >=20 > 4. Some people mentioned that the HA should be able to revoke flows on > the MN. I'm perfectly fine with that, just extend the binding = revocation > draft to handle flows and the rest is pretty straight forward. >=20 > Finally, I'll indulge in a true story that happened to me a few years > ago when I found that my wifi link wasn't working in a hotel (no = radio) > and called the help desk. He insisted that the link was up an I = insisted > that it wasn't. When I asked him to tell me how he knows the link is = up > he said: I can ping the AP! Of course after another 5 minutes of = trying > to convince him that pinging the AP doesn't mean the radio is actually > working he sent someone to the hotel who in turn realised that the = radio > was not working. > For those people who want rules to be transferred from the HA to the = MN, > please think of your HA as this help desk person, i.e. it has no clue > about what's happening at the other end. >=20 > I hope this helps with the realisation that decisions can't be made = here > based on voting and that there is little merit to transferring rules > from the HA to the MN. Policies can be transferred without any = problems, > but not rules. >=20 > Hesham >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From behcetsarikaya@yahoo.com Tue Jun 2 07:40:34 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D3F3A6FEB for ; Tue, 2 Jun 2009 07:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 o9PPFn9vTZ-9 for ; Tue, 2 Jun 2009 07:40:33 -0700 (PDT) Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id B72543A6FE4 for ; Tue, 2 Jun 2009 07:40:33 -0700 (PDT) Received: (qmail 94174 invoked by uid 60001); 2 Jun 2009 14:40:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1243953633; bh=BzyeGcmX/v+PnraZg+otwFj82pwDgBYvgNVr9o2iwa0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=x82U9Wq4FG88yCPH+uIA/b/o9dOdwW/BX5oDpvtIutzXT1dAEM3FZdmS83KNwhW7Ltt6WzaR5VAZfMkNNmz2a8ji5PtTuk4G6pkzBEmNXPdAkpwHHeTbek+s9VhyYNjTqCAqbfUPAcJkPsCUocGWHyjtVfqdfmAzShQMjA2xw/o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HMQAt8QMIDpWsCuXaYdoSwE4TRQCXUujlDBoqygcGuJbvF41OMZXICvnHewKLRoAypR90qEO7gXiuApC33nYXzpamRg6ZwnveiGIwoeHxZaVwV3xyb6injxxgujgL/HvH73RiypBdbgh7vOEgfBFcQWt8LjaCCtwsqkgkLJ6g9o=; Message-ID: <136648.90834.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: l4AhTcEVM1njVrV09x1NdyR1_qW2drDyfdd9bAD4XxgQ7sBYiMA14j9O8Im0iyryaOq9qsCI.5.UwEM0CedituXYLUBgXkw.EbiGX_sLPQD2BUWhdDRFTQOl_9gbx8eEEHbvcYQwhOPPb8mXxmQALrkkemqGJ09z.CTrF0ob5B_kt8HDaOogXQaUTWS_evcPLYovpIoaGjTdhis3nuv72iY29YeIKPWZeTDnwbVcD7FuYxzp3gYLNkCayOxvcaprPuLa.ACeC7xkqBYZ5TgR9PKyuntQJbLH3tHerle8gMwDyWwcbymwG1gl3EkkTNpDtbu5UCUPwsA- Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Tue, 02 Jun 2009 07:40:32 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <7ad6d6db0906020542s5b29e869i6b13bd8db989bf43@mail.gmail.com> Date: Tue, 2 Jun 2009 07:40:32 -0700 (PDT) From: Behcet Sarikaya To: Julien Laganier , Yuri Ismailov In-Reply-To: <7ad6d6db0906020542s5b29e869i6b13bd8db989bf43@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] Important considerations for directionality of flow bindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 14:40:34 -0000 It seems like some people are drawing paralels with PMIPv6 here.=0AI think = that we shouldn't because in mext we have full MN input, e.g. MCoA draft is= a good example. MCoA draft is now in IESG processing status.=0A=0ACheers,= =0A=0ABehcet=0A=0A=0A=A0=0A=0A=0A----- Original Message ----=0AFrom: Julien= Laganier =0ATo: Yuri Ismailov =0ACc: mext =0ASent: Tuesday, June 2, 2= 009 7:42:23 AM=0ASubject: Re: [MEXT] Important considerations for direction= ality of flow bindings=0A=0AYuri,=0A=0AOn Fri, May 29, 2009 at 9:35 AM, Yur= i Ismailov=0A wrote:=0A> Hesham,=0A>=0A> This i= s nice story and makes some sense for the discssion, however some=0A> detai= ls are ommited. In your adventure with the helpdesk, it (the helpdesk)=0A> = is a third party service and thus your conclusions make sence. Think of the= =0A> situation when superior of a heldesk person will tell him/her to check= =0A> access point in some room. Would it be the same reaction? I assume not= . By=0A> that I mean that if, for example, I'll install home agent in my ho= me=0A> network, I can make it know anything I want about MN, and more intre= sting is=0A> that how I will do it, does not=A0require any standardization.= In other words,=0A> I'm superior of my HA.=0A=0AI have nothing against bei= ng the superior or having one, but I'm a bit=0Alost with the point of the a= nalogy...=0A=0AHow do you make your HA know that the address XYZ your MN ju= st SLAAC'd=0Aat the starbucks downdown is assigned towards on a 54Mbs WiFi = link?=0AAre you driving back to home to configure appropriately your HA whi= le=0Athe MN stays at starbucks?=0A=0A> This situation is not unthinkable, I= =A0personally believe that this is much=0A> more efficient way of using HA = fnctionality as opposed to big service=0A> providers who will have to fight= with scalability and performance. However,=0A> one does not exclude anothe= r.=0A>=0A> Difference between policies and rules is a convertion step. Is t= here any=0A> reason to restrict where such convertion takes place?=0A=0AI b= elieve there's a valid reason which is called protocol layering.=0ARules de= aling with choice of a MIPv6 Care-of address do belong to the=0AMIPv6 layer= . Policies regarding which access technology to use for a=0Agiven app/servi= ce/etc. do not belong to that layer.=0A=0A> True that a HA does=0A> not kno= w what is going on in the access network, on the other hand HA may=0A> know= what is the network condition between HA and correspondent node. Either=0A= > of this information is important, if not equally important.=0A=0ANobody s= aid information X is not important while information Y is.=0A=0AAn informat= ion is important in a given context. I do not care what's=0Athe status of y= our WiFi card, I care about the status of my card.=0A=0AThe point is, the i= nformation of what is happening on the links to=0Awhich the MN is attached = is of utmost importance in choosing which=0Acare-of address to use because = the choice of care-of address in turns=0Aimplies the choice of a link, and = this is most likely a wireless link.=0A=0AOn the other hand, choosing a car= e-of adddress has no impact nor is=0Aimpacted by the network conditions bet= ween the HA and the=0Acorrespondent node.=0A=0A> BTW, what is the numerical= representation of "rough consensus"? I assume is=0A> when majority is for,= is it so?=0A=0A51% majority is not "rough consensus", this is voting.=0A= =0A--julien=0A_______________________________________________=0AMEXT mailin= g list=0AMEXT@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/mext=0A=0A= =0A=0A From yuri.ismailov@ericsson.com Tue Jun 2 08:37:33 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F15C63A6F3F for ; Tue, 2 Jun 2009 08:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 11-tP32vSvC6 for ; Tue, 2 Jun 2009 08:37:32 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 3F1953A693A for ; Tue, 2 Jun 2009 08:37:30 -0700 (PDT) X-AuditID: c1b4fb3e-b7b4bae00000395e-6b-4a254737b998 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 23.D9.14686.737452A4; Tue, 2 Jun 2009 17:37:27 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jun 2009 16:17:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Jun 2009 16:17:21 +0200 Message-ID: In-Reply-To: <7ad6d6db0906020542s5b29e869i6b13bd8db989bf43@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flow bindings Thread-Index: Acnjf5QY2xs1llgPSQe1H1TTFmGKeAABB69g References: <7ad6d6db0906020542s5b29e869i6b13bd8db989bf43@mail.gmail.com> From: "Yuri Ismailov" To: "Julien Laganier" X-OriginalArrivalTime: 02 Jun 2009 14:17:21.0938 (UTC) FILETIME=[D83A0F20:01C9E38C] X-Brightmail-Tracker: AAAAAA== Cc: mext Subject: Re: [MEXT] Important considerations for directionality of flow bindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 15:37:34 -0000 Julien, Probably some missunderstanding comes from the different scope of = viewing at the general deployment of MIP protocol(s) I'm trying (whether successful or not?) not to restrict the view to just = flow binding as such but to look at somewhat bigger context where MIP = support is a part of the whole, playing important role. > How do you make your HA know that the address XYZ your MN just SLAAC'd = at the starbucks downdown is assigned towards on a 54Mbs WiFi link? > Are you driving back to home to configure appropriately your HA while = the MN stays at starbucks? The key is that one may use (I definetly would) applciation level to = communicate any kind of parameters between HA and MN. I do not mean = routing rules. Basically anything else. If one finds that the fact of MN = being attached to 54Mbs WiFi link is useful information for HA, then = there is nothing preventing to send this information to HA without = involving MIP. Next important thing, in my view, is that the logic generating this or = that set of routing rules whether implemented in MN or HA or both has = nothing to do with MIP. This logic is about how to choose an interface = for a particular flow and in theory may be delegated to a third party = node (do not think this is a good idea though). This is the reason why I = don't entirely agree with your statement: > I believe there's a valid reason which is called protocol layering. > Rules dealing with choice of a MIPv6 Care-of address do belong to the > MIPv6 layer. Policies regarding which access technology to use for a = given app/service/etc. do not belong to that layer Basically rules is instantiation of policies and as I see it, first the = choice of access is made, secondly an IP address is pointed out, but not = because the IP address is suitable for a flow or belongs to IP layer, = but because it turned out to be configured on the suitable access. Thus, = I would not state that rules are dealing with any kind of choice, on the = other hand rules are the result of choice. > > An information is important in a given context. I do not care what's = the status of your WiFi card, I care about the status of my card. > This is sad:-) If you could get a hint about my status, you could = possibly make a better choice. Not for the sake of analogy, just an = example: SIP has negotiation procedure of session parameters, which = makes things nicer. The word "hint" characterizes quite well the fact of = sending rules from HA to MN. As I wrote earlier, MN does not have to = follow the HA generated rules, however may take into account. > > 51% majority is not "rough consensus", this is voting. > What is the rough consensus then? Who decides that the rough consensus = is achieved? Regards Yuri -----Original Message----- From: Julien Laganier [mailto:julien.laganier.ietf@googlemail.com]=20 Sent: Tuesday, June 02, 2009 2:42 PM To: Yuri Ismailov Cc: Hesham Soliman; mext Subject: Re: [MEXT] Important considerations for directionality of flow = bindings Yuri, On Fri, May 29, 2009 at 9:35 AM, Yuri Ismailov = wrote: > Hesham, > > This is nice story and makes some sense for the discssion, however=20 > some details are ommited. In your adventure with the helpdesk, it (the = > helpdesk) is a third party service and thus your conclusions make=20 > sence. Think of the situation when superior of a heldesk person will=20 > tell him/her to check access point in some room. Would it be the same=20 > reaction? I assume not. By that I mean that if, for example, I'll=20 > install home agent in my home network, I can make it know anything I=20 > want about MN, and more intresting is that how I will do it, does = not=A0 > require any standardization. In other words, I'm superior of my HA. I have nothing against being the superior or having one, but I'm a bit = lost with the point of the analogy... How do you make your HA know that the address XYZ your MN just SLAAC'd = at the starbucks downdown is assigned towards on a 54Mbs WiFi link? Are you driving back to home to configure appropriately your HA while = the MN stays at starbucks? > This situation is not unthinkable, I=A0personally believe that this is = > much more efficient way of using HA fnctionality as opposed to big=20 > service providers who will have to fight with scalability and=20 > performance. However, one does not exclude another. > > Difference between policies and rules is a convertion step. Is there=20 > any reason to restrict where such convertion takes place? I believe there's a valid reason which is called protocol layering. Rules dealing with choice of a MIPv6 Care-of address do belong to the MIPv6 layer. Policies regarding which access technology to use for a = given app/service/etc. do not belong to that layer. > True that a HA does > not know what is going on in the access network, on the other hand HA=20 > may know what is the network condition between HA and correspondent=20 > node. Either of this information is important, if not equally = important. Nobody said information X is not important while information Y is. An information is important in a given context. I do not care what's the = status of your WiFi card, I care about the status of my card. The point is, the information of what is happening on the links to which = the MN is attached is of utmost importance in choosing which care-of = address to use because the choice of care-of address in turns implies = the choice of a link, and this is most likely a wireless link. On the other hand, choosing a care-of adddress has no impact nor is = impacted by the network conditions between the HA and the correspondent = node. > BTW, what is the numerical representation of "rough consensus"? I=20 > assume is when majority is for, is it so? 51% majority is not "rough consensus", this is voting. --julien From ietf@montavont.net Tue Jun 2 08:46:39 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5F2A28C23B for ; Tue, 2 Jun 2009 08:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 ys3dSia8o9CQ for ; Tue, 2 Jun 2009 08:46:38 -0700 (PDT) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by core3.amsl.com (Postfix) with ESMTP id 1616A3A7023 for ; Tue, 2 Jun 2009 08:46:37 -0700 (PDT) Received: by fxm12 with SMTP id 12so6609792fxm.37 for ; Tue, 02 Jun 2009 08:46:36 -0700 (PDT) Received: by 10.86.70.12 with SMTP id s12mr8059073fga.69.1243957596044; Tue, 02 Jun 2009 08:46:36 -0700 (PDT) Received: from ?192.168.103.210? (pat46-invites.rennes.enst-bretagne.fr [192.44.77.46]) by mx.google.com with ESMTPS id d6sm14093393fga.2.2009.06.02.08.46.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 02 Jun 2009 08:46:35 -0700 (PDT) Message-Id: From: Nicolas Montavont To: In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462191437@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 2 Jun 2009 17:46:34 +0200 References: <843DA8228A1BA74CA31FB4E111A5C462191437@ftrdmel0.rd.francetelecom.fr> X-Mailer: Apple Mail (2.935.3) Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 15:46:39 -0000 Hi Pierrick, On Jun 2, 2009, at 4:11 PM, wrote: > > Hi all, > > Please see inline comment. > > Regards, > Pierrick > >> ________________________________________ >> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la =20 >> part de >> Yuri Ismailov >> Envoy=E9 : vendredi 29 mai 2009 09:35 >> =C0 : Hesham Soliman; mext >> Objet : Re: [MEXT] Important considerations for directionality of >> flowbindings >> >> Hesham, >> This is nice story and makes some sense for the discssion, however =20= >> some >> details are ommited. In your adventure with the helpdesk, it (the >> helpdesk) is a third party service and thus your conclusions make =20 >> sence. >> Think of the situation when superior of a heldesk person will tell =20= >> him/her >> to check access point in some room. Would it be the same reaction? I >> assume not. By that I mean that if, for example, I'll install home =20= >> agent >> in my home network, I can make it know anything I want about MN, =20 >> and more >> intresting is that how I will do it, does not require any =20 >> standardization. >> In other words, I'm superior of my HA. >> This situation is not unthinkable, I personally believe that this =20 >> is much >> more efficient way of using HA fnctionality as opposed to big service >> providers who will have to fight with scalability and performance. >> However, one does not exclude another. >> Difference between policies and rules is a convertion step. >> >> > > > The difference between policy and rules is not only a matter of =20 > conversion. A policy, is a static, or quasi-static, set of guidance =20= > for the MN (e.g use access network X for application type A,...) =20 > while a rule update requires to be more dynamic. I mean: eventually =20= > a policy could be updated depending on network condition (e.g if X =20 > overloaded, use access network Y for application type A,...) but a =20 > rule reacts on local triggers (e.g. modification of the radio link =20 > quality) with a shorter period of variation. So, IMHO, there is no =20 > requirement for updating policy on a short period and out-of-band =20 > mechanism can be used (e.g. IEEE 802.21 in push mode,...). Fully agree! This is why I do not support the exchange of rules from the HA to the =20= MN. Policies may be exchanged from the HA to the MN, but MIP is =20 definitely not the protocol to transport them. Nicolas > > > My 2 cents... > >> >> Is there any reason to restrict where such convertion takes place? =20= >> True >> that a HA does not know what is going on in the access network, on =20= >> the >> other hand HA may know what is the network condition between HA and >> correspondent node. Either of this information is important, if not >> equally important. >> It is not really difficult to let an MN to reject rules sent by HA, =20= >> which >> in my view would be quite natural. This implies that HA must follow =20= >> the >> rules installed by MN until explicit acceptance has been received =20 >> from MN. >> Such procedure is very similar to an MN beahviour when initiating =20 >> new BU, >> where MN is not supposed to send any traffic before BU confirmation. >> BTW, what is the numerical representation of "rough consensus"? I =20 >> assume >> is when majority is for, is it so? >> Yuri >> >> >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On =20 >> Behalf Of >> Hesham Soliman >> Sent: Thursday, May 28, 2009 12:07 PM >> To: mext >> Subject: [MEXT] Important considerations for directionality of flow >> bindings >> >> Hi all, >> >> I've always been a fan of the IETF's tradition of rough concensus (as >> opposed to voting). To me, this implies that you need to get your =20 >> point >> across and get other people to see that point of view. As opposed to >> other organisations that require their members to vote and end up =20 >> with >> rigid political positions. >> >> The chairs asked us about the directionality question of the flows >> bindings. >> On the charter question, I said that the charter doesn't need to =20 >> mention >> how a solution should work, but rather what problem needs to be =20 >> solved. >> Hence, as far as the charter is concerned, I'm fine with transferring >> rules "between" the MN and HA without mentioning directions. >> >> Nevertheless, we still need to agree on identifying the requirement =20= >> for >> the solution. And when it comes to this, I'm strongly against =20 >> voting and >> I'll practice this by explaining in this email why I think rules =20 >> can not >> be transferred from the HA to the MN and that the only direction that >> makes sense in MIP is MN->HA. I'll deliberately ignore arguments like >> "some people want this" or "an SDO wants this". They fall under the >> "meaningless words" >> category and I'm incapable of discussing them because they come with >> voting attitudes. They all need to be justified if the WG wants to =20= >> have >> a technical _discussion_. >> >> Here are my reasons: >> >> 1. The HA does not know whether a CoA is tied to a certain access >> technology. It is one thing for the HA to send a message saying =20 >> "forward >> port 80 traffic on a wifi link" (a policy) and a completely different >> thing to say "forward port 80 traffic using CoA 3ffe::1" (a rule). >> >> 2. You might argue that the HA can be told by the MN that 3ffe::1 is >> tied to a wifi access, so what's the problem now? The problem is that >> the HA has no idea about dynamic changes on that wifi link. It =20 >> doesn't >> know if it's congested, it doesn't know what application is using =20 >> port >> 80 (it doesn't have to be web traffic) or port 8000 for that matter =20= >> and >> doesn't even know if the AP of that wifi link works at all. =20 >> Finally, it >> doesn't know the user's policies or other admin policies for that MN. >> This type of information needs to be sent regularly because it =20 >> changes >> all the time and requires serious cross layer integration including >> sometimes layer 8 integration! It's completely impractical. >> >> 3. If the HA installed rules in the MN, what happens if the MN =20 >> wants to >> change those rules. Say the wifi link went down, or the MN's wifi >> interface went down and it wants to move that traffic to another >> interface. Would the HA reject such move? Does the MN have to =20 >> justify to >> the HA why it needs to move traffic? Does that involve writing a =20 >> letter >> perhaps? >> If you say "well in that case, the HA should let the MN move the >> traffic" >> then I'll ask you: what's the point of having the HA install this =20 >> stuff >> if it has no authority and how does it know the reason for the MN's >> movement of the flow? >> The way to control how users do things is to incentivise them with >> charging models and show them that things work better on certain >> technologies, not by installing rules that can't be followed. It's a >> broken mindset and we've known that it's broken for a long time. >> >> 4. Some people mentioned that the HA should be able to revoke flows =20= >> on >> the MN. I'm perfectly fine with that, just extend the binding =20 >> revocation >> draft to handle flows and the rest is pretty straight forward. >> >> Finally, I'll indulge in a true story that happened to me a few years >> ago when I found that my wifi link wasn't working in a hotel (no =20 >> radio) >> and called the help desk. He insisted that the link was up an I =20 >> insisted >> that it wasn't. When I asked him to tell me how he knows the link =20 >> is up >> he said: I can ping the AP! Of course after another 5 minutes of =20 >> trying >> to convince him that pinging the AP doesn't mean the radio is =20 >> actually >> working he sent someone to the hotel who in turn realised that the =20= >> radio >> was not working. >> For those people who want rules to be transferred from the HA to =20 >> the MN, >> please think of your HA as this help desk person, i.e. it has no clue >> about what's happening at the other end. >> >> I hope this helps with the realisation that decisions can't be made =20= >> here >> based on voting and that there is little merit to transferring rules >> from the HA to the MN. Policies can be transferred without any =20 >> problems, >> but not rules. >> >> Hesham >> >> >> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From tsirtsis@googlemail.com Tue Jun 2 08:55:02 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52A913A693A for ; Tue, 2 Jun 2009 08:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2] 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 iJw9vkDhrxy9 for ; Tue, 2 Jun 2009 08:54:54 -0700 (PDT) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by core3.amsl.com (Postfix) with ESMTP id C94043A702A for ; Tue, 2 Jun 2009 08:54:53 -0700 (PDT) Received: by fxm12 with SMTP id 12so6615750fxm.37 for ; Tue, 02 Jun 2009 08:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1h+bw/5Wwt5PTPbNI0CO6e1/jBkcTB00lXcJCWyuLyk=; b=G1bKvKQn3YkTRIozOQZNEGu/S1XvuthjnO7YKyCj993h2tbWYW2ukEFnWr0S3pmXkV cXliikO5hP6jBZ2Y/1E+J330lY9QGYIuCr163pxnYralstq9sv9Agi2w/PTSsnZ0ILli qtkD8oA2qeB0PtJlf7hJVHgDexwNLyso23XIk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Eyb+TU5PpH0tKPlXHMGuwmebK7VO40hmotXvwJM+ewSZaka3JV9CSMWqce3H0XHQDx 5HgZ0rslpWkpGS8kEraFudxaqeoVOnaaXb/ncs7ApLAAI19GkA67HHSIIJcNI7gq3XUq VP64MXNlMbm2ThWWwPWMFDU1M7GkiJH6s/Frs= MIME-Version: 1.0 Received: by 10.223.113.9 with SMTP id y9mr3702298fap.61.1243958092478; Tue, 02 Jun 2009 08:54:52 -0700 (PDT) In-Reply-To: References: <843DA8228A1BA74CA31FB4E111A5C462191437@ftrdmel0.rd.francetelecom.fr> Date: Tue, 2 Jun 2009 16:54:50 +0100 Message-ID: From: George Tsirtsis To: Nicolas Montavont Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 15:55:02 -0000 FWIW I also fully agree with this as well as with Hesham's main points. Although I understand that some people find the prospect of an HA micromanaging uplink flows interesting at an academic level, I do not think anyone would seriously consider this in a practical deployment for reasons that have already been exhaustively articulated. Regards George On Tue, Jun 2, 2009 at 4:46 PM, Nicolas Montavont wrot= e: > Hi Pierrick, > > On Jun 2, 2009, at 4:11 PM, wrote: > >> >> Hi all, >> >> Please see inline comment. >> >> Regards, >> Pierrick >> >>> ________________________________________ >>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de >>> Yuri Ismailov >>> Envoy=C3=A9 : vendredi 29 mai 2009 09:35 >>> =C3=80 : Hesham Soliman; mext >>> Objet : Re: [MEXT] Important considerations for directionality of >>> flowbindings >>> >>> Hesham, >>> This is nice story and makes some sense for the discssion, however some >>> details are ommited. In your adventure with the helpdesk, it (the >>> helpdesk) is a third party service and thus your conclusions make sence= . >>> Think of the situation when superior of a heldesk person will tell >>> him/her >>> to check access point in some room. Would it be the same reaction? I >>> assume not. By that I mean that if, for example, I'll install home agen= t >>> in my home network, I can make it know anything I want about MN, and mo= re >>> intresting is that how I will do it, does not require any >>> standardization. >>> In other words, I'm superior of my HA. >>> This situation is not unthinkable, I personally believe that this is mu= ch >>> more efficient way of using HA fnctionality as opposed to big service >>> providers who will have to fight with scalability and performance. >>> However, one does not exclude another. >>> Difference between policies and rules is a convertion step. >>> >>> >> >> >> The difference between policy and rules is not only a matter of >> conversion. A policy, is a static, or quasi-static, set of guidance for = the >> MN (e.g use access network X for application type A,...) while a rule up= date >> requires to be more dynamic. I mean: eventually a policy could be update= d >> depending on network condition (e.g if X overloaded, use access network = Y >> for application type A,...) but a rule reacts on local triggers (e.g. >> modification of the radio link quality) with a shorter period of variati= on. >> So, IMHO, there is no requirement for updating policy on a short period = and >> out-of-band mechanism can be used (e.g. IEEE 802.21 in push mode,...). > > Fully agree! > This is why I do not support the exchange of rules from the HA to the MN. > Policies may be exchanged from the HA to the MN, but MIP is definitely no= t > the protocol to transport them. > > Nicolas > >> >> >> My 2 cents... >> >>> >>> Is there any reason to restrict where such convertion takes place? True >>> that a HA does not know what is going on in the access network, on the >>> other hand HA may know what is the network condition between HA and >>> correspondent node. Either of this information is important, if not >>> equally important. >>> It is not really difficult to let an MN to reject rules sent by HA, whi= ch >>> in my view would be quite natural. This implies that HA must follow the >>> rules installed by MN until explicit acceptance has been received from >>> MN. >>> Such procedure is very similar to an MN beahviour when initiating new B= U, >>> where MN is not supposed to send any traffic before BU confirmation. >>> BTW, what is the numerical representation of "rough consensus"? I assum= e >>> is when majority is for, is it so? >>> Yuri >>> >>> >>> -----Original Message----- >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of >>> Hesham Soliman >>> Sent: Thursday, May 28, 2009 12:07 PM >>> To: mext >>> Subject: [MEXT] Important considerations for directionality of flow >>> bindings >>> >>> Hi all, >>> >>> I've always been a fan of the IETF's tradition of rough concensus (as >>> opposed to voting). To me, this implies that you need to get your point >>> across and get other people to see that point of view. As opposed to >>> other organisations that require their members to vote and end up with >>> rigid political positions. >>> >>> The chairs asked us about the directionality question of the flows >>> bindings. >>> On the charter question, I said that the charter doesn't need to mentio= n >>> how a solution should work, but rather what problem needs to be solved. >>> Hence, as far as the charter is concerned, I'm fine with transferring >>> rules "between" the MN and HA without mentioning directions. >>> >>> Nevertheless, we still need to agree on identifying the requirement for >>> the solution. And when it comes to this, I'm strongly against voting an= d >>> I'll practice this by explaining in this email why I think rules can no= t >>> be transferred from the HA to the MN and that the only direction that >>> makes sense in MIP is MN->HA. I'll deliberately ignore arguments like >>> "some people want this" or "an SDO wants this". They fall under the >>> "meaningless words" >>> category and I'm incapable of discussing them because they come with >>> voting attitudes. They all need to be justified if the WG wants to have >>> a technical _discussion_. >>> >>> Here are my reasons: >>> >>> 1. The HA does not know whether a CoA is tied to a certain access >>> technology. It is one thing for the HA to send a message saying "forwar= d >>> port 80 traffic on a wifi link" (a policy) and a completely different >>> thing to say "forward port 80 traffic using CoA 3ffe::1" (a rule). >>> >>> 2. You might argue that the HA can be told by the MN that 3ffe::1 is >>> tied to a wifi access, so what's the problem now? The problem is that >>> the HA has no idea about dynamic changes on that wifi link. It doesn't >>> know if it's congested, it doesn't know what application is using port >>> 80 (it doesn't have to be web traffic) or port 8000 for that matter and >>> doesn't even know if the AP of that wifi link works at all. Finally, it >>> doesn't know the user's policies or other admin policies for that MN. >>> This type of information needs to be sent regularly because it changes >>> all the time and requires serious cross layer integration including >>> sometimes layer 8 integration! It's completely impractical. >>> >>> 3. If the HA installed rules in the MN, what happens if the MN wants to >>> change those rules. Say the wifi link went down, or the MN's wifi >>> interface went down and it wants to move that traffic to another >>> interface. Would the HA reject such move? Does the MN have to justify t= o >>> the HA why it needs to move traffic? Does that involve writing a letter >>> perhaps? >>> If you say "well in that case, the HA should let the MN move the >>> traffic" >>> then I'll ask you: what's the point of having the HA install this stuff >>> if it has no authority and how does it know the reason for the MN's >>> movement of the flow? >>> The way to control how users do things is to incentivise them with >>> charging models and show them that things work better on certain >>> technologies, not by installing rules that can't be followed. It's a >>> broken mindset and we've known that it's broken for a long time. >>> >>> 4. Some people mentioned that the HA should be able to revoke flows on >>> the MN. I'm perfectly fine with that, just extend the binding revocatio= n >>> draft to handle flows and the rest is pretty straight forward. >>> >>> Finally, I'll indulge in a true story that happened to me a few years >>> ago when I found that my wifi link wasn't working in a hotel (no radio) >>> and called the help desk. He insisted that the link was up an I insiste= d >>> that it wasn't. When I asked him to tell me how he knows the link is up >>> he said: I can ping the AP! Of course after another 5 minutes of trying >>> to convince him that pinging the AP doesn't mean the radio is actually >>> working he sent someone to the hotel who in turn realised that the radi= o >>> was not working. >>> For those people who want rules to be transferred from the HA to the MN= , >>> please think of your HA as this help desk person, i.e. it has no clue >>> about what's happening at the other end. >>> >>> I hope this helps with the realisation that decisions can't be made her= e >>> based on voting and that there is little merit to transferring rules >>> from the HA to the MN. Policies can be transferred without any problems= , >>> but not rules. >>> >>> Hesham >>> >>> >>> >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From behcetsarikaya@yahoo.com Tue Jun 2 09:19:33 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0B9A3A6CB3 for ; Tue, 2 Jun 2009 09:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 EmyD52nNK-Xk for ; Tue, 2 Jun 2009 09:19:32 -0700 (PDT) Received: from n69.bullet.mail.sp1.yahoo.com (n69.bullet.mail.sp1.yahoo.com [98.136.44.41]) by core3.amsl.com (Postfix) with SMTP id 3410A3A6F9E for ; Tue, 2 Jun 2009 09:19:03 -0700 (PDT) Received: from [69.147.84.144] by n69.bullet.mail.sp1.yahoo.com with NNFMP; 02 Jun 2009 16:19:02 -0000 Received: from [67.195.9.81] by t6.bullet.mail.sp1.yahoo.com with NNFMP; 02 Jun 2009 16:19:02 -0000 Received: from [67.195.9.103] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 02 Jun 2009 16:19:02 -0000 Received: from [127.0.0.1] by omp107.mail.gq1.yahoo.com with NNFMP; 02 Jun 2009 16:18:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 742921.70192.bm@omp107.mail.gq1.yahoo.com Received: (qmail 27227 invoked by uid 60001); 2 Jun 2009 16:19:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1243959542; bh=vYTOmoeBqWQxOMAMPAeayMW2+mZ/7ePrD0evmBxqjRc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ygTqDWJxovIIppJ1nhy9HxvCpU/sgs3JWkVKT7qhStMJv2B16M3R7l4y1EA9TeyWUtQGerN55qa/OKLPIPzvnbtYgofgrJUtaHgi+uZ91E3uofDA3hkuJ64ZvxRylwT1nSmAqxLA+h0DSRaXWySyUyGvYsmPpWJuk2vBwe7jFJE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=InkEV9NZwpBhAVC+dvm6H/sAuTxL2WE0Z72Ny9+re6DncOC53OCoRtR0agD7AWyU81ZavNAhs3f14OslzDcHHEDQyUh+NnKzaEoF3GaGM392M11cDmBQURi02eQCfUaJTHymfl1YW2wq2al8+dCQ7Md88bvszrq4I13G1Ru8Di8=; Message-ID: <99007.27110.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: 5Brs7u0VM1ncUw4oz92X16fTJmXZYiLy4W1IQyyGAfINEmt9EPm9kIK3xDUYPJvUyFbpuhOIwzM_tw6hr6QTFkaw1O0TXIFju.9NUm2ouMGF5Jw84LTwiUqrSfdtttSCeTIrQFhMyVXy8LRytN0RXybTx5rydSycpYhU07jvKsxN5OPEQINBFfHl08PxwEegmDxbSDLdYoxfAHydsJuCP87IDOh9SFwVqdZbtNtlc6vEjXduy1_PvTwfP9YEqa1V3aai3COxqqvWLf55px8UmRBVKhqHrqwFUJRBy2ONqK0aVV6s6ZDQHVBorxBUaJ6icEa4g_i21ifSAQ-- Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Tue, 02 Jun 2009 09:19:01 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <843DA8228A1BA74CA31FB4E111A5C462191437@ftrdmel0.rd.francetelecom.fr> Date: Tue, 2 Jun 2009 09:19:01 -0700 (PDT) From: Behcet Sarikaya To: George Tsirtsis , Nicolas Montavont In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 16:19:33 -0000 First it was:=0ANo HA can not do, only MN can do it.=0A=0A=0ANow it suddenl= y became:=0AYes it is possible but academic :).=0A=0A=0A=0ARegards,=0A=0ABe= hcet=0A=0A=0A=0A----- Original Message ----=0AFrom: George Tsirtsis =0ATo: Nicolas Montavont =0ACc: mext@= ietf.org=0ASent: Tuesday, June 2, 2009 10:54:50 AM=0ASubject: Re: [MEXT] Im= portant considerations for directionality of flowbindings=0A=0AFWIW I also = fully agree with this as well as with Hesham's main points.=0A=0AAlthough I= understand that some people find the prospect of an HA=0Amicromanaging upl= ink flows interesting at an academic level, I do not=0Athink anyone would s= eriously consider this in a practical deployment=0Afor reasons that have al= ready been exhaustively articulated.=0A=0ARegards=0AGeorge=0A=0A=0A=0AOn Tu= e, Jun 2, 2009 at 4:46 PM, Nicolas Montavont wrote:=0A= > Hi Pierrick,=0A>=0A> On Jun 2, 2009, at 4:11 PM, wrote:=0A>=0A>>=0A>> Hi all,=0A>>=0A>> Please see inline commen= t.=0A>>=0A>> Regards,=0A>> Pierrick=0A>>=0A>>> ____________________________= ____________=0A>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org= ] De la part de=0A>>> Yuri Ismailov=0A>>> Envoy=E9 : vendredi 29 mai 2009 0= 9:35=0A>>> =C0 : Hesham Soliman; mext=0A>>> Objet : Re: [MEXT] Important co= nsiderations for directionality of=0A>>> flowbindings=0A>>>=0A>>> Hesham,= =0A>>> This is nice story and makes some sense for the discssion, however s= ome=0A>>> details are ommited. In your adventure with the helpdesk, it (the= =0A>>> helpdesk) is a third party service and thus your conclusions make se= nce.=0A>>> Think of the situation when superior of a heldesk person will te= ll=0A>>> him/her=0A>>> to check access point in some room. Would it be the = same reaction? I=0A>>> assume not. By that I mean that if, for example, I'l= l install home agent=0A>>> in my home network, I can make it know anything = I want about MN, and more=0A>>> intresting is that how I will do it, does n= ot require any=0A>>> standardization.=0A>>> In other words, I'm superior of= my HA.=0A>>> This situation is not unthinkable, I personally believe that = this is much=0A>>> more efficient way of using HA fnctionality as opposed t= o big service=0A>>> providers who will have to fight with scalability and p= erformance.=0A>>> However, one does not exclude another.=0A>>> Difference b= etween policies and rules is a convertion step.=0A>>>=0A>>>=0A>>=0A>>=0A>> = The difference between policy and rules is not only a matter of=0A>> conver= sion. A policy, is a static, or quasi-static, set of guidance for the=0A>> = MN (e.g use access network X for application type A,...) while a rule updat= e=0A>> requires to be more dynamic. I mean: eventually a policy could be up= dated=0A>> depending on network condition (e.g if X overloaded, use access = network Y=0A>> for application type A,...) but a rule reacts on local trigg= ers (e.g.=0A>> modification of the radio link quality) with a shorter perio= d of variation.=0A>> So, IMHO, there is no requirement for updating policy = on a short period and=0A>> out-of-band mechanism can be used (e.g. IEEE 802= ..21 in push mode,...).=0A>=0A> Fully agree!=0A> This is why I do not suppor= t the exchange of rules from the HA to the MN.=0A> Policies may be exchange= d from the HA to the MN, but MIP is definitely not=0A> the protocol to tran= sport them.=0A>=0A> Nicolas=0A>=0A>>=0A>>=0A>> My 2 cents...=0A>>=0A>>>=0A>= >> Is there any reason to restrict where such convertion takes place? True= =0A>>> that a HA does not know what is going on in the access network, on t= he=0A>>> other hand HA may know what is the network condition between HA an= d=0A>>> correspondent node. Either of this information is important, if not= =0A>>> equally important.=0A>>> It is not really difficult to let an MN to = reject rules sent by HA, which=0A>>> in my view would be quite natural. Thi= s implies that HA must follow the=0A>>> rules installed by MN until explici= t acceptance has been received from=0A>>> MN.=0A>>> Such procedure is very = similar to an MN beahviour when initiating new BU,=0A>>> where MN is not su= pposed to send any traffic before BU confirmation.=0A>>> BTW, what is the n= umerical representation of "rough consensus"? I assume=0A>>> is when majori= ty is for, is it so?=0A>>> Yuri=0A>>>=0A>>>=0A>>> -----Original Message----= -=0A>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behal= f Of=0A>>> Hesham Soliman=0A>>> Sent: Thursday, May 28, 2009 12:07 PM=0A>>>= To: mext=0A>>> Subject: [MEXT] Important considerations for directionality= of flow=0A>>> bindings=0A>>>=0A>>> Hi all,=0A>>>=0A>>> I've always been a = fan of the IETF's tradition of rough concensus (as=0A>>> opposed to voting)= .. To me, this implies that you need to get your point=0A>>> across and get = other people to see that point of view. As opposed to=0A>>> other organisat= ions that require their members to vote and end up with=0A>>> rigid politic= al positions.=0A>>>=0A>>> The chairs asked us about the directionality ques= tion of the flows=0A>>> bindings.=0A>>> On the charter question, I said tha= t the charter doesn't need to mention=0A>>> how a solution should work, but= rather what problem needs to be solved.=0A>>> Hence, as far as the charter= is concerned, I'm fine with transferring=0A>>> rules "between" the MN and = HA without mentioning directions.=0A>>>=0A>>> Nevertheless, we still need t= o agree on identifying the requirement for=0A>>> the solution. And when it = comes to this, I'm strongly against voting and=0A>>> I'll practice this by = explaining in this email why I think rules can not=0A>>> be transferred fro= m the HA to the MN and that the only direction that=0A>>> makes sense in MI= P is MN->HA. I'll deliberately ignore arguments like=0A>>> "some people wan= t this" or "an SDO wants this". They fall under the=0A>>> "meaningless word= s"=0A>>> category and I'm incapable of discussing them because they come wi= th=0A>>> voting attitudes. They all need to be justified if the WG wants to= have=0A>>> a technical _discussion_.=0A>>>=0A>>> Here are my reasons:=0A>>= >=0A>>> 1. The HA does not know whether a CoA is tied to a certain access= =0A>>> technology. It is one thing for the HA to send a message saying "for= ward=0A>>> port 80 traffic on a wifi link" (a policy) and a completely diff= erent=0A>>> thing to say "forward port 80 traffic using CoA 3ffe::1" (a rul= e).=0A>>>=0A>>> 2. You might argue that the HA can be told by the MN that 3= ffe::1 is=0A>>> tied to a wifi access, so what's the problem now? The probl= em is that=0A>>> the HA has no idea about dynamic changes on that wifi link= .. It doesn't=0A>>> know if it's congested, it doesn't know what application= is using port=0A>>> 80 (it doesn't have to be web traffic) or port 8000 fo= r that matter and=0A>>> doesn't even know if the AP of that wifi link works= at all. Finally, it=0A>>> doesn't know the user's policies or other admin = policies for that MN.=0A>>> This type of information needs to be sent regul= arly because it changes=0A>>> all the time and requires serious cross layer= integration including=0A>>> sometimes layer 8 integration! It's completely= impractical.=0A>>>=0A>>> 3. If the HA installed rules in the MN, what happ= ens if the MN wants to=0A>>> change those rules. Say the wifi link went dow= n, or the MN's wifi=0A>>> interface went down and it wants to move that tra= ffic to another=0A>>> interface. Would the HA reject such move? Does the MN= have to justify to=0A>>> the HA why it needs to move traffic? Does that in= volve writing a letter=0A>>> perhaps?=0A>>> If you say "well in that case, = the HA should let the MN move the=0A>>> traffic"=0A>>> then I'll ask you: w= hat's the point of having the HA install this stuff=0A>>> if it has no auth= ority and how does it know the reason for the MN's=0A>>> movement of the fl= ow?=0A>>> The way to control how users do things is to incentivise them wit= h=0A>>> charging models and show them that things work better on certain=0A= >>> technologies, not by installing rules that can't be followed. It's a=0A= >>> broken mindset and we've known that it's broken for a long time.=0A>>>= =0A>>> 4. Some people mentioned that the HA should be able to revoke flows = on=0A>>> the MN. I'm perfectly fine with that, just extend the binding revo= cation=0A>>> draft to handle flows and the rest is pretty straight forward.= =0A>>>=0A>>> Finally, I'll indulge in a true story that happened to me a fe= w years=0A>>> ago when I found that my wifi link wasn't working in a hotel = (no radio)=0A>>> and called the help desk. He insisted that the link was up= an I insisted=0A>>> that it wasn't. When I asked him to tell me how he kno= ws the link is up=0A>>> he said: I can ping the AP! Of course after another= 5 minutes of trying=0A>>> to convince him that pinging the AP doesn't mean= the radio is actually=0A>>> working he sent someone to the hotel who in tu= rn realised that the radio=0A>>> was not working.=0A>>> For those people wh= o want rules to be transferred from the HA to the MN,=0A>>> please think of= your HA as this help desk person, i.e. it has no clue=0A>>> about what's h= appening at the other end.=0A>>>=0A>>> I hope this helps with the realisati= on that decisions can't be made here=0A>>> based on voting and that there i= s little merit to transferring rules=0A>>> from the HA to the MN. Policies = can be transferred without any problems,=0A>>> but not rules.=0A>>>=0A>>> H= esham=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>>> _________________________________= ______________=0A>>> MEXT mailing list=0A>>> MEXT@ietf.org=0A>>> https://ww= w.ietf.org/mailman/listinfo/mext=0A>>> ____________________________________= ___________=0A>>> MEXT mailing list=0A>>> MEXT@ietf.org=0A>>> https://www.i= etf.org/mailman/listinfo/mext=0A>>=0A>> ___________________________________= ____________=0A>> MEXT mailing list=0A>> MEXT@ietf.org=0A>> https://www.iet= f.org/mailman/listinfo/mext=0A>=0A> _______________________________________= ________=0A> MEXT mailing list=0A> MEXT@ietf.org=0A> https://www.ietf.org/m= ailman/listinfo/mext=0A>=0A_______________________________________________= =0AMEXT mailing list=0AMEXT@ietf.org=0Ahttps://www.ietf.org/mailman/listinf= o/mext=0A=0A=0A=0A From tsirtsis@googlemail.com Tue Jun 2 09:22:40 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D3CA3A6B90 for ; Tue, 2 Jun 2009 09:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2] 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 x8886HbVsfkP for ; Tue, 2 Jun 2009 09:22:38 -0700 (PDT) Received: from mail-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by core3.amsl.com (Postfix) with ESMTP id D40923A67F6 for ; Tue, 2 Jun 2009 09:22:37 -0700 (PDT) Received: by bwz22 with SMTP id 22so8277593bwz.37 for ; Tue, 02 Jun 2009 09:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=auQRM73GWAxRMwXubM+TVUZXQslr187UpqU5HtRWdQc=; b=r3uHqhVHwA+7cI0uBxegkOu2yv1swsd/Qwt2PlKic+Lrkm+tlVBhot26bX4TnPql+b LWCheFuez1zJ3JeCg1hwvX0Rad1+C4lR/Et0Fc8VAM+0vf5tkMr23TWS+GHCHsn0WbNG l1Mvf9M52TNR26ZdWyZqlu+oSfxD/aIlAQTX0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fdI/2F/9HYJneU60L0A9MnswdybT8imirHKB6Zipb4GXnJReCPNFsDy4RpLZvRheh5 QPCsLLCYaJKmx/izVgVyyJ3fh6uYOSehdaQYDEN7ZmlpbOtQRyFvcns9+3MjrQfrByaK mWIO5Ll6AGSjwXr3rM4Yipic0cRR0OsHGw8W0= MIME-Version: 1.0 Received: by 10.223.108.15 with SMTP id d15mr3761168fap.62.1243959755832; Tue, 02 Jun 2009 09:22:35 -0700 (PDT) In-Reply-To: <99007.27110.qm@web111413.mail.gq1.yahoo.com> References: <843DA8228A1BA74CA31FB4E111A5C462191437@ftrdmel0.rd.francetelecom.fr> <99007.27110.qm@web111413.mail.gq1.yahoo.com> Date: Tue, 2 Jun 2009 17:22:35 +0100 Message-ID: From: George Tsirtsis To: Behcet Sarikaya Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 16:22:40 -0000 A lot of things are theoretically possible. We are not here, however, to standardise all theoretical possibilities. On Tue, Jun 2, 2009 at 5:19 PM, Behcet Sarikaya wrote: > > First it was: > No HA can not do, only MN can do it. > > > Now it suddenly became: > Yes it is possible but academic :). > > > > Regards, > > Behcet > > > > ----- Original Message ---- > From: George Tsirtsis > To: Nicolas Montavont > Cc: mext@ietf.org > Sent: Tuesday, June 2, 2009 10:54:50 AM > Subject: Re: [MEXT] Important considerations for directionality of flowbi= ndings > > FWIW I also fully agree with this as well as with Hesham's main points. > > Although I understand that some people find the prospect of an HA > micromanaging uplink flows interesting at an academic level, I do not > think anyone would seriously consider this in a practical deployment > for reasons that have already been exhaustively articulated. > > Regards > George > > > > On Tue, Jun 2, 2009 at 4:46 PM, Nicolas Montavont wr= ote: >> Hi Pierrick, >> >> On Jun 2, 2009, at 4:11 PM, wrote: >> >>> >>> Hi all, >>> >>> Please see inline comment. >>> >>> Regards, >>> Pierrick >>> >>>> ________________________________________ >>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part d= e >>>> Yuri Ismailov >>>> Envoy=C3=A9 : vendredi 29 mai 2009 09:35 >>>> =C3=80 : Hesham Soliman; mext >>>> Objet : Re: [MEXT] Important considerations for directionality of >>>> flowbindings >>>> >>>> Hesham, >>>> This is nice story and makes some sense for the discssion, however som= e >>>> details are ommited. In your adventure with the helpdesk, it (the >>>> helpdesk) is a third party service and thus your conclusions make senc= e. >>>> Think of the situation when superior of a heldesk person will tell >>>> him/her >>>> to check access point in some room. Would it be the same reaction? I >>>> assume not. By that I mean that if, for example, I'll install home age= nt >>>> in my home network, I can make it know anything I want about MN, and m= ore >>>> intresting is that how I will do it, does not require any >>>> standardization. >>>> In other words, I'm superior of my HA. >>>> This situation is not unthinkable, I personally believe that this is m= uch >>>> more efficient way of using HA fnctionality as opposed to big service >>>> providers who will have to fight with scalability and performance. >>>> However, one does not exclude another. >>>> Difference between policies and rules is a convertion step. >>>> >>>> >>> >>> >>> The difference between policy and rules is not only a matter of >>> conversion. A policy, is a static, or quasi-static, set of guidance for= the >>> MN (e.g use access network X for application type A,...) while a rule u= pdate >>> requires to be more dynamic. I mean: eventually a policy could be updat= ed >>> depending on network condition (e.g if X overloaded, use access network= Y >>> for application type A,...) but a rule reacts on local triggers (e.g. >>> modification of the radio link quality) with a shorter period of variat= ion. >>> So, IMHO, there is no requirement for updating policy on a short period= and >>> out-of-band mechanism can be used (e.g. IEEE 802..21 in push mode,...). >> >> Fully agree! >> This is why I do not support the exchange of rules from the HA to the MN= . >> Policies may be exchanged from the HA to the MN, but MIP is definitely n= ot >> the protocol to transport them. >> >> Nicolas >> >>> >>> >>> My 2 cents... >>> >>>> >>>> Is there any reason to restrict where such convertion takes place? Tru= e >>>> that a HA does not know what is going on in the access network, on the >>>> other hand HA may know what is the network condition between HA and >>>> correspondent node. Either of this information is important, if not >>>> equally important. >>>> It is not really difficult to let an MN to reject rules sent by HA, wh= ich >>>> in my view would be quite natural. This implies that HA must follow th= e >>>> rules installed by MN until explicit acceptance has been received from >>>> MN. >>>> Such procedure is very similar to an MN beahviour when initiating new = BU, >>>> where MN is not supposed to send any traffic before BU confirmation. >>>> BTW, what is the numerical representation of "rough consensus"? I assu= me >>>> is when majority is for, is it so? >>>> Yuri >>>> >>>> >>>> -----Original Message----- >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf O= f >>>> Hesham Soliman >>>> Sent: Thursday, May 28, 2009 12:07 PM >>>> To: mext >>>> Subject: [MEXT] Important considerations for directionality of flow >>>> bindings >>>> >>>> Hi all, >>>> >>>> I've always been a fan of the IETF's tradition of rough concensus (as >>>> opposed to voting).. To me, this implies that you need to get your poi= nt >>>> across and get other people to see that point of view. As opposed to >>>> other organisations that require their members to vote and end up with >>>> rigid political positions. >>>> >>>> The chairs asked us about the directionality question of the flows >>>> bindings. >>>> On the charter question, I said that the charter doesn't need to menti= on >>>> how a solution should work, but rather what problem needs to be solved= . >>>> Hence, as far as the charter is concerned, I'm fine with transferring >>>> rules "between" the MN and HA without mentioning directions. >>>> >>>> Nevertheless, we still need to agree on identifying the requirement fo= r >>>> the solution. And when it comes to this, I'm strongly against voting a= nd >>>> I'll practice this by explaining in this email why I think rules can n= ot >>>> be transferred from the HA to the MN and that the only direction that >>>> makes sense in MIP is MN->HA. I'll deliberately ignore arguments like >>>> "some people want this" or "an SDO wants this". They fall under the >>>> "meaningless words" >>>> category and I'm incapable of discussing them because they come with >>>> voting attitudes. They all need to be justified if the WG wants to hav= e >>>> a technical _discussion_. >>>> >>>> Here are my reasons: >>>> >>>> 1. The HA does not know whether a CoA is tied to a certain access >>>> technology. It is one thing for the HA to send a message saying "forwa= rd >>>> port 80 traffic on a wifi link" (a policy) and a completely different >>>> thing to say "forward port 80 traffic using CoA 3ffe::1" (a rule). >>>> >>>> 2. You might argue that the HA can be told by the MN that 3ffe::1 is >>>> tied to a wifi access, so what's the problem now? The problem is that >>>> the HA has no idea about dynamic changes on that wifi link.. It doesn'= t >>>> know if it's congested, it doesn't know what application is using port >>>> 80 (it doesn't have to be web traffic) or port 8000 for that matter an= d >>>> doesn't even know if the AP of that wifi link works at all. Finally, i= t >>>> doesn't know the user's policies or other admin policies for that MN. >>>> This type of information needs to be sent regularly because it changes >>>> all the time and requires serious cross layer integration including >>>> sometimes layer 8 integration! It's completely impractical. >>>> >>>> 3. If the HA installed rules in the MN, what happens if the MN wants t= o >>>> change those rules. Say the wifi link went down, or the MN's wifi >>>> interface went down and it wants to move that traffic to another >>>> interface. Would the HA reject such move? Does the MN have to justify = to >>>> the HA why it needs to move traffic? Does that involve writing a lette= r >>>> perhaps? >>>> If you say "well in that case, the HA should let the MN move the >>>> traffic" >>>> then I'll ask you: what's the point of having the HA install this stuf= f >>>> if it has no authority and how does it know the reason for the MN's >>>> movement of the flow? >>>> The way to control how users do things is to incentivise them with >>>> charging models and show them that things work better on certain >>>> technologies, not by installing rules that can't be followed. It's a >>>> broken mindset and we've known that it's broken for a long time. >>>> >>>> 4. Some people mentioned that the HA should be able to revoke flows on >>>> the MN. I'm perfectly fine with that, just extend the binding revocati= on >>>> draft to handle flows and the rest is pretty straight forward. >>>> >>>> Finally, I'll indulge in a true story that happened to me a few years >>>> ago when I found that my wifi link wasn't working in a hotel (no radio= ) >>>> and called the help desk. He insisted that the link was up an I insist= ed >>>> that it wasn't. When I asked him to tell me how he knows the link is u= p >>>> he said: I can ping the AP! Of course after another 5 minutes of tryin= g >>>> to convince him that pinging the AP doesn't mean the radio is actually >>>> working he sent someone to the hotel who in turn realised that the rad= io >>>> was not working. >>>> For those people who want rules to be transferred from the HA to the M= N, >>>> please think of your HA as this help desk person, i.e. it has no clue >>>> about what's happening at the other end. >>>> >>>> I hope this helps with the realisation that decisions can't be made he= re >>>> based on voting and that there is little merit to transferring rules >>>> from the HA to the MN. Policies can be transferred without any problem= s, >>>> but not rules. >>>> >>>> Hesham >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > > > > From xiayangsong@huawei.com Tue Jun 2 09:38:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EBE43A6A26 for ; Tue, 2 Jun 2009 09:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 tDCkbFdP1XTo for ; Tue, 2 Jun 2009 09:38:23 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 9098E3A68DD for ; Tue, 2 Jun 2009 09:38:23 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKM00CJUE7PKI@szxga02-in.huawei.com> for mext@ietf.org; Wed, 03 Jun 2009 00:38:14 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKM00148E7PRE@szxga02-in.huawei.com> for mext@ietf.org; Wed, 03 Jun 2009 00:38:13 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKM00LG2E7K4M@szxml04-in.huawei.com> for mext@ietf.org; Wed, 03 Jun 2009 00:38:11 +0800 (CST) Date: Tue, 02 Jun 2009 11:38:08 -0500 From: Frank Xia To: Nicolas Montavont , pierrick.seite@orange-ftgroup.com Message-id: <001c01c9e3a0$8441ff40$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <843DA8228A1BA74CA31FB4E111A5C462191437@ftrdmel0.rd.francetelecom.fr> Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 16:38:25 -0000 Hi Nicolas and Pierrick As for policy and rules which you think policy is static while rules are dynamic, I don't think I have the same understanding as you. In 3GPP/TISPAN, PCRF ( Policy and Charging Rules function entity) could enforce PCC (Policy and Charging Control)dynamically. There is not such a difference which you highlighted. BR Frank ----- Original Message ----- From: "Nicolas Montavont" To: Cc: Sent: Tuesday, June 02, 2009 10:46 AM Subject: Re: [MEXT] Important considerations for directionality of flowbindings Hi Pierrick, On Jun 2, 2009, at 4:11 PM, wrote: > > Hi all, > > Please see inline comment. > > Regards, > Pierrick > >> ________________________________________ >> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de >> Yuri Ismailov >> Envoyé : vendredi 29 mai 2009 09:35 >> À : Hesham Soliman; mext >> Objet : Re: [MEXT] Important considerations for directionality of >> flowbindings >> >> Hesham, >> This is nice story and makes some sense for the discssion, however some >> details are ommited. In your adventure with the helpdesk, it (the >> helpdesk) is a third party service and thus your conclusions make sence. >> Think of the situation when superior of a heldesk person will tell >> him/her >> to check access point in some room. Would it be the same reaction? I >> assume not. By that I mean that if, for example, I'll install home agent >> in my home network, I can make it know anything I want about MN, and >> more >> intresting is that how I will do it, does not require any >> standardization. >> In other words, I'm superior of my HA. >> This situation is not unthinkable, I personally believe that this is >> much >> more efficient way of using HA fnctionality as opposed to big service >> providers who will have to fight with scalability and performance. >> However, one does not exclude another. >> Difference between policies and rules is a convertion step. >> >> > > > The difference between policy and rules is not only a matter of > conversion. A policy, is a static, or quasi-static, set of guidance for > the MN (e.g use access network X for application type A,...) while a rule > update requires to be more dynamic. I mean: eventually a policy could be > updated depending on network condition (e.g if X overloaded, use access > network Y for application type A,...) but a rule reacts on local triggers > (e.g. modification of the radio link quality) with a shorter period of > variation. So, IMHO, there is no requirement for updating policy on a > short period and out-of-band mechanism can be used (e.g. IEEE 802.21 in > push mode,...). Fully agree! This is why I do not support the exchange of rules from the HA to the MN. Policies may be exchanged from the HA to the MN, but MIP is definitely not the protocol to transport them. Nicolas > > > My 2 cents... > >> >> Is there any reason to restrict where such convertion takes place? True >> that a HA does not know what is going on in the access network, on the >> other hand HA may know what is the network condition between HA and >> correspondent node. Either of this information is important, if not >> equally important. >> It is not really difficult to let an MN to reject rules sent by HA, >> which >> in my view would be quite natural. This implies that HA must follow the >> rules installed by MN until explicit acceptance has been received from >> MN. >> Such procedure is very similar to an MN beahviour when initiating new >> BU, >> where MN is not supposed to send any traffic before BU confirmation. >> BTW, what is the numerical representation of "rough consensus"? I assume >> is when majority is for, is it so? >> Yuri >> >> >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of >> Hesham Soliman >> Sent: Thursday, May 28, 2009 12:07 PM >> To: mext >> Subject: [MEXT] Important considerations for directionality of flow >> bindings >> >> Hi all, >> >> I've always been a fan of the IETF's tradition of rough concensus (as >> opposed to voting). To me, this implies that you need to get your point >> across and get other people to see that point of view. As opposed to >> other organisations that require their members to vote and end up with >> rigid political positions. >> >> The chairs asked us about the directionality question of the flows >> bindings. >> On the charter question, I said that the charter doesn't need to mention >> how a solution should work, but rather what problem needs to be solved. >> Hence, as far as the charter is concerned, I'm fine with transferring >> rules "between" the MN and HA without mentioning directions. >> >> Nevertheless, we still need to agree on identifying the requirement for >> the solution. And when it comes to this, I'm strongly against voting and >> I'll practice this by explaining in this email why I think rules can not >> be transferred from the HA to the MN and that the only direction that >> makes sense in MIP is MN->HA. I'll deliberately ignore arguments like >> "some people want this" or "an SDO wants this". They fall under the >> "meaningless words" >> category and I'm incapable of discussing them because they come with >> voting attitudes. They all need to be justified if the WG wants to have >> a technical _discussion_. >> >> Here are my reasons: >> >> 1. The HA does not know whether a CoA is tied to a certain access >> technology. It is one thing for the HA to send a message saying "forward >> port 80 traffic on a wifi link" (a policy) and a completely different >> thing to say "forward port 80 traffic using CoA 3ffe::1" (a rule). >> >> 2. You might argue that the HA can be told by the MN that 3ffe::1 is >> tied to a wifi access, so what's the problem now? The problem is that >> the HA has no idea about dynamic changes on that wifi link. It doesn't >> know if it's congested, it doesn't know what application is using port >> 80 (it doesn't have to be web traffic) or port 8000 for that matter and >> doesn't even know if the AP of that wifi link works at all. Finally, it >> doesn't know the user's policies or other admin policies for that MN. >> This type of information needs to be sent regularly because it changes >> all the time and requires serious cross layer integration including >> sometimes layer 8 integration! It's completely impractical. >> >> 3. If the HA installed rules in the MN, what happens if the MN wants to >> change those rules. Say the wifi link went down, or the MN's wifi >> interface went down and it wants to move that traffic to another >> interface. Would the HA reject such move? Does the MN have to justify to >> the HA why it needs to move traffic? Does that involve writing a letter >> perhaps? >> If you say "well in that case, the HA should let the MN move the >> traffic" >> then I'll ask you: what's the point of having the HA install this stuff >> if it has no authority and how does it know the reason for the MN's >> movement of the flow? >> The way to control how users do things is to incentivise them with >> charging models and show them that things work better on certain >> technologies, not by installing rules that can't be followed. It's a >> broken mindset and we've known that it's broken for a long time. >> >> 4. Some people mentioned that the HA should be able to revoke flows on >> the MN. I'm perfectly fine with that, just extend the binding revocation >> draft to handle flows and the rest is pretty straight forward. >> >> Finally, I'll indulge in a true story that happened to me a few years >> ago when I found that my wifi link wasn't working in a hotel (no radio) >> and called the help desk. He insisted that the link was up an I insisted >> that it wasn't. When I asked him to tell me how he knows the link is up >> he said: I can ping the AP! Of course after another 5 minutes of trying >> to convince him that pinging the AP doesn't mean the radio is actually >> working he sent someone to the hotel who in turn realised that the radio >> was not working. >> For those people who want rules to be transferred from the HA to the MN, >> please think of your HA as this help desk person, i.e. it has no clue >> about what's happening at the other end. >> >> I hope this helps with the realisation that decisions can't be made here >> based on voting and that there is little merit to transferring rules >> from the HA to the MN. Policies can be transferred without any problems, >> but not rules. >> >> Hesham >> >> >> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From behcetsarikaya@yahoo.com Tue Jun 2 09:42:33 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E6373A6FEB for ; Tue, 2 Jun 2009 09:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 DY3SXSEzFPgM for ; Tue, 2 Jun 2009 09:42:32 -0700 (PDT) Received: from n57.bullet.mail.sp1.yahoo.com (n57.bullet.mail.sp1.yahoo.com [98.136.44.49]) by core3.amsl.com (Postfix) with SMTP id 142FE3A6F2D for ; Tue, 2 Jun 2009 09:42:32 -0700 (PDT) Received: from [216.252.122.216] by n57.bullet.mail.sp1.yahoo.com with NNFMP; 02 Jun 2009 16:42:33 -0000 Received: from [67.195.9.81] by t1.bullet.sp1.yahoo.com with NNFMP; 02 Jun 2009 16:42:33 -0000 Received: from [67.195.9.111] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 02 Jun 2009 16:42:33 -0000 Received: from [127.0.0.1] by omp115.mail.gq1.yahoo.com with NNFMP; 02 Jun 2009 16:42:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 183920.93489.bm@omp115.mail.gq1.yahoo.com Received: (qmail 41297 invoked by uid 60001); 2 Jun 2009 16:42:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1243960952; bh=/GqIx9acDg8ROPFQIHKOKJbcAx/ZWVWOgmK7a6nu0ZY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OP4UwYG2BGFJN5+qeU/Zelu1les7M5+0N3gracNvWwPfXINLD2q4GwXgamUHqPSjeEIS2yuFe+cc7W1K2G31khc1DxMy8iD5fRoaB6sA0yVDb//MFznN7mh2cgsDA6wa5g2jvqGuASlZUaqDPdNnqARaX26f09mlpQm365pE3UY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0zX4+x7Ve3lIpGPxP5LhTZYrfmUFEi7AvMinSvtKfGvtAjKbMoHLDmJVsEdfRe+VRA9rcXYbpESJDRzheNmCVFjiss54ELQtHmwBs6UFkgYVbJvHzGTQ2FsZCIYwH7NY7qkHnP/kYAORIoXL9fLnGyW5Axz2z336lipohDZBM9E=; Message-ID: <514487.40624.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: NqT6UCsVM1nIhk8ETuaSy92cJI2SmWgHbFuTaH8Gob5.Kx7S8JxrUL5rQSOGCPKMr1aSMRLbziISn031S6K0cgosARAv6ZJcHdIzAt8Mvn2ioNmcOOhTAbvN98IMDd5V1ACFxz52LuNjxdbid1Y2B4bVsfGFXZkj9Dq_o8z5TKCOboBETpfIHiqJVB6pzbOrBHLxFm6QJ5KCUqexv2KhTUFxD1T3I1AQAQVP_AT5RV0Xk8RcFX5sQt9KB7K58l4sOjfcDEil.IS8zJ7fovjw4G.0WphNDz1P_1OuXm0xAQ5PMkBaZ7oaM18OJjvWd8F70XnRRu0- Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Tue, 02 Jun 2009 09:42:32 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <843DA8228A1BA74CA31FB4E111A5C462191437@ftrdmel0.rd.francetelecom.fr> <99007.27110.qm@web111413.mail.gq1.yahoo.com> Date: Tue, 2 Jun 2009 09:42:32 -0700 (PDT) From: Behcet Sarikaya To: George Tsirtsis In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 16:42:33 -0000 Yes IETF has already standardized "theoretical possibilities" with RFC 3543= in 2003, why not another one that was inherited from one of the founding f= athers of mext called monami6?=0A=0A=0A=A0=0A=0A=0A----- Original Message -= ---=0AFrom: George Tsirtsis =0ATo: Behcet Sarikaya= =0ACc: Nicolas Montavont ; mext@iet= f.org=0ASent: Tuesday, June 2, 2009 11:22:35 AM=0ASubject: Re: [MEXT] Impor= tant considerations for directionality of flowbindings=0A=0AA lot of things= are theoretically possible.=0AWe are not here, however, to standardise all= theoretical possibilities.=0A=0AOn Tue, Jun 2, 2009 at 5:19 PM, Behcet Sar= ikaya=0A wrote:=0A>=0A> First it was:=0A> No HA c= an not do, only MN can do it.=0A>=0A>=0A> Now it suddenly became:=0A> Yes i= t is possible but academic :).=0A>=0A>=0A>=0A> Regards,=0A>=0A> Behcet=0A>= =0A>=0A>=0A> ----- Original Message ----=0A> From: George Tsirtsis =0A> To: Nicolas Montavont =0A> Cc: me= xt@ietf.org=0A> Sent: Tuesday, June 2, 2009 10:54:50 AM=0A> Subject: Re: [M= EXT] Important considerations for directionality of flowbindings=0A>=0A> FW= IW I also fully agree with this as well as with Hesham's main points.=0A>= =0A> Although I understand that some people find the prospect of an HA=0A> = micromanaging uplink flows interesting at an academic level, I do not=0A> t= hink anyone would seriously consider this in a practical deployment=0A> for= reasons that have already been exhaustively articulated.=0A>=0A> Regards= =0A> George=0A>=0A>=0A>=0A> On Tue, Jun 2, 2009 at 4:46 PM, Nicolas Montavo= nt wrote:=0A>> Hi Pierrick,=0A>>=0A>> On Jun 2, 2009, = at 4:11 PM, wrote:=0A>>=0A>>>=0A>>> Hi = all,=0A>>>=0A>>> Please see inline comment.=0A>>>=0A>>> Regards,=0A>>> Pier= rick=0A>>>=0A>>>> ________________________________________=0A>>>> De : mext= -bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de=0A>>>> Yuri = Ismailov=0A>>>> Envoy=E9 : vendredi 29 mai 2009 09:35=0A>>>> =C0 : Hesham S= oliman; mext=0A>>>> Objet : Re: [MEXT] Important considerations for directi= onality of=0A>>>> flowbindings=0A>>>>=0A>>>> Hesham,=0A>>>> This is nice st= ory and makes some sense for the discssion, however some=0A>>>> details are= ommited. In your adventure with the helpdesk, it (the=0A>>>> helpdesk) is = a third party service and thus your conclusions make sence.=0A>>>> Think of= the situation when superior of a heldesk person will tell=0A>>>> him/her= =0A>>>> to check access point in some room. Would it be the same reaction? = I=0A>>>> assume not. By that I mean that if, for example, I'll install home= agent=0A>>>> in my home network, I can make it know anything I want about = MN, and more=0A>>>> intresting is that how I will do it, does not require a= ny=0A>>>> standardization.=0A>>>> In other words, I'm superior of my HA.=0A= >>>> This situation is not unthinkable, I personally believe that this is m= uch=0A>>>> more efficient way of using HA fnctionality as opposed to big se= rvice=0A>>>> providers who will have to fight with scalability and performa= nce.=0A>>>> However, one does not exclude another.=0A>>>> Difference betwee= n policies and rules is a convertion step.=0A>>>>=0A>>>>=0A>>>=0A>>>=0A>>> = The difference between policy and rules is not only a matter of=0A>>> conve= rsion. A policy, is a static, or quasi-static, set of guidance for the=0A>>= > MN (e.g use access network X for application type A,...) while a rule upd= ate=0A>>> requires to be more dynamic. I mean: eventually a policy could be= updated=0A>>> depending on network condition (e.g if X overloaded, use acc= ess network Y=0A>>> for application type A,...) but a rule reacts on local = triggers (e.g.=0A>>> modification of the radio link quality) with a shorter= period of variation.=0A>>> So, IMHO, there is no requirement for updating = policy on a short period and=0A>>> out-of-band mechanism can be used (e.g. = IEEE 802..21 in push mode,...).=0A>>=0A>> Fully agree!=0A>> This is why I d= o not support the exchange of rules from the HA to the MN.=0A>> Policies ma= y be exchanged from the HA to the MN, but MIP is definitely not=0A>> the pr= otocol to transport them.=0A>>=0A>> Nicolas=0A>>=0A>>>=0A>>>=0A>>> My 2 cen= ts...=0A>>>=0A>>>>=0A>>>> Is there any reason to restrict where such conver= tion takes place? True=0A>>>> that a HA does not know what is going on in t= he access network, on the=0A>>>> other hand HA may know what is the network= condition between HA and=0A>>>> correspondent node. Either of this informa= tion is important, if not=0A>>>> equally important.=0A>>>> It is not really= difficult to let an MN to reject rules sent by HA, which=0A>>>> in my view= would be quite natural. This implies that HA must follow the=0A>>>> rules = installed by MN until explicit acceptance has been received from=0A>>>> MN.= =0A>>>> Such procedure is very similar to an MN beahviour when initiating n= ew BU,=0A>>>> where MN is not supposed to send any traffic before BU confir= mation.=0A>>>> BTW, what is the numerical representation of "rough consensu= s"? I assume=0A>>>> is when majority is for, is it so?=0A>>>> Yuri=0A>>>>= =0A>>>>=0A>>>> -----Original Message-----=0A>>>> From: mext-bounces@ietf.or= g [mailto:mext-bounces@ietf.org] On Behalf Of=0A>>>> Hesham Soliman=0A>>>> = Sent: Thursday, May 28, 2009 12:07 PM=0A>>>> To: mext=0A>>>> Subject: [MEXT= ] Important considerations for directionality of flow=0A>>>> bindings=0A>>>= >=0A>>>> Hi all,=0A>>>>=0A>>>> I've always been a fan of the IETF's traditi= on of rough concensus (as=0A>>>> opposed to voting).. To me, this implies t= hat you need to get your point=0A>>>> across and get other people to see th= at point of view. As opposed to=0A>>>> other organisations that require the= ir members to vote and end up with=0A>>>> rigid political positions.=0A>>>>= =0A>>>> The chairs asked us about the directionality question of the flows= =0A>>>> bindings.=0A>>>> On the charter question, I said that the charter d= oesn't need to mention=0A>>>> how a solution should work, but rather what p= roblem needs to be solved.=0A>>>> Hence, as far as the charter is concerned= , I'm fine with transferring=0A>>>> rules "between" the MN and HA without m= entioning directions.=0A>>>>=0A>>>> Nevertheless, we still need to agree on= identifying the requirement for=0A>>>> the solution. And when it comes to = this, I'm strongly against voting and=0A>>>> I'll practice this by explaini= ng in this email why I think rules can not=0A>>>> be transferred from the H= A to the MN and that the only direction that=0A>>>> makes sense in MIP is M= N->HA. I'll deliberately ignore arguments like=0A>>>> "some people want thi= s" or "an SDO wants this". They fall under the=0A>>>> "meaningless words"= =0A>>>> category and I'm incapable of discussing them because they come wit= h=0A>>>> voting attitudes. They all need to be justified if the WG wants to= have=0A>>>> a technical _discussion_.=0A>>>>=0A>>>> Here are my reasons:= =0A>>>>=0A>>>> 1. The HA does not know whether a CoA is tied to a certain a= ccess=0A>>>> technology. It is one thing for the HA to send a message sayin= g "forward=0A>>>> port 80 traffic on a wifi link" (a policy) and a complete= ly different=0A>>>> thing to say "forward port 80 traffic using CoA 3ffe::1= " (a rule).=0A>>>>=0A>>>> 2. You might argue that the HA can be told by the= MN that 3ffe::1 is=0A>>>> tied to a wifi access, so what's the problem now= ? The problem is that=0A>>>> the HA has no idea about dynamic changes on th= at wifi link.. It doesn't=0A>>>> know if it's congested, it doesn't know wh= at application is using port=0A>>>> 80 (it doesn't have to be web traffic) = or port 8000 for that matter and=0A>>>> doesn't even know if the AP of that= wifi link works at all. Finally, it=0A>>>> doesn't know the user's policie= s or other admin policies for that MN.=0A>>>> This type of information need= s to be sent regularly because it changes=0A>>>> all the time and requires = serious cross layer integration including=0A>>>> sometimes layer 8 integrat= ion! It's completely impractical.=0A>>>>=0A>>>> 3. If the HA installed rule= s in the MN, what happens if the MN wants to=0A>>>> change those rules. Say= the wifi link went down, or the MN's wifi=0A>>>> interface went down and i= t wants to move that traffic to another=0A>>>> interface. Would the HA reje= ct such move? Does the MN have to justify to=0A>>>> the HA why it needs to = move traffic? Does that involve writing a letter=0A>>>> perhaps?=0A>>>> If = you say "well in that case, the HA should let the MN move the=0A>>>> traffi= c"=0A>>>> then I'll ask you: what's the point of having the HA install this= stuff=0A>>>> if it has no authority and how does it know the reason for th= e MN's=0A>>>> movement of the flow?=0A>>>> The way to control how users do = things is to incentivise them with=0A>>>> charging models and show them tha= t things work better on certain=0A>>>> technologies, not by installing rule= s that can't be followed. It's a=0A>>>> broken mindset and we've known that= it's broken for a long time.=0A>>>>=0A>>>> 4. Some people mentioned that t= he HA should be able to revoke flows on=0A>>>> the MN. I'm perfectly fine w= ith that, just extend the binding revocation=0A>>>> draft to handle flows a= nd the rest is pretty straight forward.=0A>>>>=0A>>>> Finally, I'll indulge= in a true story that happened to me a few years=0A>>>> ago when I found th= at my wifi link wasn't working in a hotel (no radio)=0A>>>> and called the = help desk. He insisted that the link was up an I insisted=0A>>>> that it wa= sn't. When I asked him to tell me how he knows the link is up=0A>>>> he sai= d: I can ping the AP! Of course after another 5 minutes of trying=0A>>>> to= convince him that pinging the AP doesn't mean the radio is actually=0A>>>>= working he sent someone to the hotel who in turn realised that the radio= =0A>>>> was not working.=0A>>>> For those people who want rules to be trans= ferred from the HA to the MN,=0A>>>> please think of your HA as this help d= esk person, i.e. it has no clue=0A>>>> about what's happening at the other = end.=0A>>>>=0A>>>> I hope this helps with the realisation that decisions ca= n't be made here=0A>>>> based on voting and that there is little merit to t= ransferring rules=0A>>>> from the HA to the MN. Policies can be transferred= without any problems,=0A>>>> but not rules.=0A>>>>=0A>>>> Hesham=0A>>>>=0A= >>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>> __________________________________________= _____=0A>>>> MEXT mailing list=0A>>>> MEXT@ietf.org=0A>>>> https://www.ietf= ..org/mailman/listinfo/mext=0A>>>> _________________________________________= ______=0A>>>> MEXT mailing list=0A>>>> MEXT@ietf.org=0A>>>> https://www.iet= f.org/mailman/listinfo/mext=0A>>>=0A>>> ___________________________________= ____________=0A>>> MEXT mailing list=0A>>> MEXT@ietf.org=0A>>> https://www.= ietf.org/mailman/listinfo/mext=0A>>=0A>> __________________________________= _____________=0A>> MEXT mailing list=0A>> MEXT@ietf.org=0A>> https://www.ie= tf.org/mailman/listinfo/mext=0A>>=0A> _____________________________________= __________=0A> MEXT mailing list=0A> MEXT@ietf.org=0A> https://www.ietf.org= /mailman/listinfo/mext=0A>=0A>=0A>=0A>=0A>=0A>=0A=0A=0A=0A From hesham@elevatemobile.com Tue Jun 2 19:58:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B9D3A6AA5 for ; Tue, 2 Jun 2009 19:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 KLejmiIEij1x for ; Tue, 2 Jun 2009 19:58:11 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 03A6F3A6A66 for ; Tue, 2 Jun 2009 19:58:09 -0700 (PDT) Received: from [115.130.24.236] by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MBgfx-0004Lg-PY; Wed, 03 Jun 2009 12:58:05 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Wed, 03 Jun 2009 12:57:53 +1000 From: Hesham Soliman To: Behcet Sarikaya , George Tsirtsis Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: Acnj9xZ1WEqQVFvBZEqr+cwOt30BOQ== In-Reply-To: <514487.40624.qm@web111402.mail.gq1.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 02:58:13 -0000 Behcet,=20 You don't understand the discussion. We're not talking about binding revocation, everyone agrees that the HA can revoke a flow binding. So stop referring to RFCs that are not being disputed... On 3/06/09 2:42 AM, "Behcet Sarikaya" wrote: >=20 > Yes IETF has already standardized "theoretical possibilities" with RFC 35= 43 in > 2003, why not another one that was inherited from one of the founding fat= hers > of mext called monami6? >=20 >=20 > =A0 >=20 >=20 > ----- Original Message ---- > From: George Tsirtsis > To: Behcet Sarikaya > Cc: Nicolas Montavont ; mext@ietf.org > Sent: Tuesday, June 2, 2009 11:22:35 AM > Subject: Re: [MEXT] Important considerations for directionality of > flowbindings >=20 > A lot of things are theoretically possible. > We are not here, however, to standardise all theoretical possibilities. >=20 > On Tue, Jun 2, 2009 at 5:19 PM, Behcet Sarikaya > wrote: >>=20 >> First it was: >> No HA can not do, only MN can do it. >>=20 >>=20 >> Now it suddenly became: >> Yes it is possible but academic :). >>=20 >>=20 >>=20 >> Regards, >>=20 >> Behcet >>=20 >>=20 >>=20 >> ----- Original Message ---- >> From: George Tsirtsis >> To: Nicolas Montavont >> Cc: mext@ietf.org >> Sent: Tuesday, June 2, 2009 10:54:50 AM >> Subject: Re: [MEXT] Important considerations for directionality of >> flowbindings >>=20 >> FWIW I also fully agree with this as well as with Hesham's main points. >>=20 >> Although I understand that some people find the prospect of an HA >> micromanaging uplink flows interesting at an academic level, I do not >> think anyone would seriously consider this in a practical deployment >> for reasons that have already been exhaustively articulated. >>=20 >> Regards >> George >>=20 >>=20 >>=20 >> On Tue, Jun 2, 2009 at 4:46 PM, Nicolas Montavont w= rote: >>> Hi Pierrick, >>>=20 >>> On Jun 2, 2009, at 4:11 PM, wrote: >>>=20 >>>>=20 >>>> Hi all, >>>>=20 >>>> Please see inline comment. >>>>=20 >>>> Regards, >>>> Pierrick >>>>=20 >>>>> ________________________________________ >>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part = de >>>>> Yuri Ismailov >>>>> Envoy=E9 : vendredi 29 mai 2009 09:35 >>>>> =C0 : Hesham Soliman; mext >>>>> Objet : Re: [MEXT] Important considerations for directionality of >>>>> flowbindings >>>>>=20 >>>>> Hesham, >>>>> This is nice story and makes some sense for the discssion, however so= me >>>>> details are ommited. In your adventure with the helpdesk, it (the >>>>> helpdesk) is a third party service and thus your conclusions make sen= ce. >>>>> Think of the situation when superior of a heldesk person will tell >>>>> him/her >>>>> to check access point in some room. Would it be the same reaction? I >>>>> assume not. By that I mean that if, for example, I'll install home ag= ent >>>>> in my home network, I can make it know anything I want about MN, and = more >>>>> intresting is that how I will do it, does not require any >>>>> standardization. >>>>> In other words, I'm superior of my HA. >>>>> This situation is not unthinkable, I personally believe that this is = much >>>>> more efficient way of using HA fnctionality as opposed to big service >>>>> providers who will have to fight with scalability and performance. >>>>> However, one does not exclude another. >>>>> Difference between policies and rules is a convertion step. >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> The difference between policy and rules is not only a matter of >>>> conversion. A policy, is a static, or quasi-static, set of guidance fo= r the >>>> MN (e.g use access network X for application type A,...) while a rule >>>> update >>>> requires to be more dynamic. I mean: eventually a policy could be upda= ted >>>> depending on network condition (e.g if X overloaded, use access networ= k Y >>>> for application type A,...) but a rule reacts on local triggers (e.g. >>>> modification of the radio link quality) with a shorter period of varia= tion. >>>> So, IMHO, there is no requirement for updating policy on a short perio= d and >>>> out-of-band mechanism can be used (e.g. IEEE 802..21 in push mode,...)= . >>>=20 >>> Fully agree! >>> This is why I do not support the exchange of rules from the HA to the M= N. >>> Policies may be exchanged from the HA to the MN, but MIP is definitely = not >>> the protocol to transport them. >>>=20 >>> Nicolas >>>=20 >>>>=20 >>>>=20 >>>> My 2 cents... >>>>=20 >>>>>=20 >>>>> Is there any reason to restrict where such convertion takes place? Tr= ue >>>>> that a HA does not know what is going on in the access network, on th= e >>>>> other hand HA may know what is the network condition between HA and >>>>> correspondent node. Either of this information is important, if not >>>>> equally important. >>>>> It is not really difficult to let an MN to reject rules sent by HA, w= hich >>>>> in my view would be quite natural. This implies that HA must follow t= he >>>>> rules installed by MN until explicit acceptance has been received fro= m >>>>> MN. >>>>> Such procedure is very similar to an MN beahviour when initiating new= BU, >>>>> where MN is not supposed to send any traffic before BU confirmation. >>>>> BTW, what is the numerical representation of "rough consensus"? I ass= ume >>>>> is when majority is for, is it so? >>>>> Yuri >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf = Of >>>>> Hesham Soliman >>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>> To: mext >>>>> Subject: [MEXT] Important considerations for directionality of flow >>>>> bindings >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> I've always been a fan of the IETF's tradition of rough concensus (as >>>>> opposed to voting).. To me, this implies that you need to get your po= int >>>>> across and get other people to see that point of view. As opposed to >>>>> other organisations that require their members to vote and end up wit= h >>>>> rigid political positions. >>>>>=20 >>>>> The chairs asked us about the directionality question of the flows >>>>> bindings. >>>>> On the charter question, I said that the charter doesn't need to ment= ion >>>>> how a solution should work, but rather what problem needs to be solve= d. >>>>> Hence, as far as the charter is concerned, I'm fine with transferring >>>>> rules "between" the MN and HA without mentioning directions. >>>>>=20 >>>>> Nevertheless, we still need to agree on identifying the requirement f= or >>>>> the solution. And when it comes to this, I'm strongly against voting = and >>>>> I'll practice this by explaining in this email why I think rules can = not >>>>> be transferred from the HA to the MN and that the only direction that >>>>> makes sense in MIP is MN->HA. I'll deliberately ignore arguments like >>>>> "some people want this" or "an SDO wants this". They fall under the >>>>> "meaningless words" >>>>> category and I'm incapable of discussing them because they come with >>>>> voting attitudes. They all need to be justified if the WG wants to ha= ve >>>>> a technical _discussion_. >>>>>=20 >>>>> Here are my reasons: >>>>>=20 >>>>> 1. The HA does not know whether a CoA is tied to a certain access >>>>> technology. It is one thing for the HA to send a message saying "forw= ard >>>>> port 80 traffic on a wifi link" (a policy) and a completely different >>>>> thing to say "forward port 80 traffic using CoA 3ffe::1" (a rule). >>>>>=20 >>>>> 2. You might argue that the HA can be told by the MN that 3ffe::1 is >>>>> tied to a wifi access, so what's the problem now? The problem is that >>>>> the HA has no idea about dynamic changes on that wifi link.. It doesn= 't >>>>> know if it's congested, it doesn't know what application is using por= t >>>>> 80 (it doesn't have to be web traffic) or port 8000 for that matter a= nd >>>>> doesn't even know if the AP of that wifi link works at all. Finally, = it >>>>> doesn't know the user's policies or other admin policies for that MN. >>>>> This type of information needs to be sent regularly because it change= s >>>>> all the time and requires serious cross layer integration including >>>>> sometimes layer 8 integration! It's completely impractical. >>>>>=20 >>>>> 3. If the HA installed rules in the MN, what happens if the MN wants = to >>>>> change those rules. Say the wifi link went down, or the MN's wifi >>>>> interface went down and it wants to move that traffic to another >>>>> interface. Would the HA reject such move? Does the MN have to justify= to >>>>> the HA why it needs to move traffic? Does that involve writing a lett= er >>>>> perhaps? >>>>> If you say "well in that case, the HA should let the MN move the >>>>> traffic" >>>>> then I'll ask you: what's the point of having the HA install this stu= ff >>>>> if it has no authority and how does it know the reason for the MN's >>>>> movement of the flow? >>>>> The way to control how users do things is to incentivise them with >>>>> charging models and show them that things work better on certain >>>>> technologies, not by installing rules that can't be followed. It's a >>>>> broken mindset and we've known that it's broken for a long time. >>>>>=20 >>>>> 4. Some people mentioned that the HA should be able to revoke flows o= n >>>>> the MN. I'm perfectly fine with that, just extend the binding revocat= ion >>>>> draft to handle flows and the rest is pretty straight forward. >>>>>=20 >>>>> Finally, I'll indulge in a true story that happened to me a few years >>>>> ago when I found that my wifi link wasn't working in a hotel (no radi= o) >>>>> and called the help desk. He insisted that the link was up an I insis= ted >>>>> that it wasn't. When I asked him to tell me how he knows the link is = up >>>>> he said: I can ping the AP! Of course after another 5 minutes of tryi= ng >>>>> to convince him that pinging the AP doesn't mean the radio is actuall= y >>>>> working he sent someone to the hotel who in turn realised that the ra= dio >>>>> was not working. >>>>> For those people who want rules to be transferred from the HA to the = MN, >>>>> please think of your HA as this help desk person, i.e. it has no clue >>>>> about what's happening at the other end. >>>>>=20 >>>>> I hope this helps with the realisation that decisions can't be made h= ere >>>>> based on voting and that there is little merit to transferring rules >>>>> from the HA to the MN. Policies can be transferred without any proble= ms, >>>>> but not rules. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf..org/mailman/listinfo/mext >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>=20 >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>=20 >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 > =20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From yuri.ismailov@ericsson.com Tue Jun 2 23:33:16 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F33F3A6877 for ; Tue, 2 Jun 2009 23:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.249 X-Spam-Level: X-Spam-Status: No, score=-7.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 Yq6J7oc7DgGF for ; Tue, 2 Jun 2009 23:33:15 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 998803A6AB5 for ; Tue, 2 Jun 2009 23:33:14 -0700 (PDT) X-AuditID: c1b4fb3e-b7b4bae00000395e-82-4a26192a2351 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 8A.22.14686.A29162A4; Wed, 3 Jun 2009 08:33:14 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jun 2009 08:32:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 08:32:00 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlg References: <843DA8228A1BA74CA31FB4E111A5C462191437@ftrdmel0.rd.francetelecom.fr> From: "Yuri Ismailov" To: "Nicolas Montavont" , X-OriginalArrivalTime: 03 Jun 2009 06:32:01.0371 (UTC) FILETIME=[00AF62B0:01C9E415] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 06:33:16 -0000 Hi all, Can someone explain why (quasi, semi, ...) static nature of rules = matters? The generation of new rules set is triggered upon various = events: intreface evants, link load report, user generated events and so = on. Whenever an event is being processed the logic has to re-evaluate = policies in order to come up with the new rules set. The new rules set = may be exactly the same as the previous one. I think what is important is the origin for rules generation and these = are EVENTS, NOT POLICIES. Obviously events are dynamic, however upon = 1000 new events arrival neither policies nor rules may change. Rules are = not dynamic because they are RULES, but because something is happening. I do entirely agree that many of the things, such as policies transfer, = interface information, and anything else you can come up with is not = related to MIP protocol. That is exactly my point! Not even rules = generation from policies based on event arrival is an integral part of = MIP. This can be implemented on a vanilla host without mobility support = but multiaccess will be at the place. It is just rules TRANSFER which is = the matter of MIP. So where is the logic when saying that MN to HA rules = transfer is a practical engineering and HA to MN is an academic = interest? Regards Yuri -----Original Message----- From: Nicolas Montavont [mailto:ietf@montavont.net]=20 Sent: Tuesday, June 02, 2009 5:47 PM To: pierrick.seite@orange-ftgroup.com Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings Hi Pierrick, On Jun 2, 2009, at 4:11 PM, wrote: > > Hi all, > > Please see inline comment. > > Regards, > Pierrick > >> ________________________________________ >> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part=20 >> de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 : Hesham=20 >> Soliman; mext Objet : Re: [MEXT] Important considerations for=20 >> directionality of flowbindings >> >> Hesham, >> This is nice story and makes some sense for the discssion, however=20 >> some details are ommited. In your adventure with the helpdesk, it=20 >> (the >> helpdesk) is a third party service and thus your conclusions make=20 >> sence. >> Think of the situation when superior of a heldesk person will tell=20 >> him/her to check access point in some room. Would it be the same=20 >> reaction? I assume not. By that I mean that if, for example, I'll=20 >> install home agent in my home network, I can make it know anything I=20 >> want about MN, and more intresting is that how I will do it, does not = >> require any standardization. >> In other words, I'm superior of my HA. >> This situation is not unthinkable, I personally believe that this is=20 >> much more efficient way of using HA fnctionality as opposed to big=20 >> service providers who will have to fight with scalability and=20 >> performance. >> However, one does not exclude another. >> Difference between policies and rules is a convertion step. >> >> > > > The difference between policy and rules is not only a matter of=20 > conversion. A policy, is a static, or quasi-static, set of guidance=20 > for the MN (e.g use access network X for application type A,...) while = > a rule update requires to be more dynamic. I mean: eventually a policy = > could be updated depending on network condition (e.g if X overloaded,=20 > use access network Y for application type A,...) but a rule reacts on=20 > local triggers (e.g. modification of the radio link > quality) with a shorter period of variation. So, IMHO, there is no=20 > requirement for updating policy on a short period and out-of-band=20 > mechanism can be used (e.g. IEEE 802.21 in push mode,...). Fully agree! This is why I do not support the exchange of rules from the HA to the = MN. Policies may be exchanged from the HA to the MN, but MIP is = definitely not the protocol to transport them. Nicolas > > > My 2 cents... > >> >> Is there any reason to restrict where such convertion takes place? =20 >> True >> that a HA does not know what is going on in the access network, on=20 >> the other hand HA may know what is the network condition between HA=20 >> and correspondent node. Either of this information is important, if=20 >> not equally important. >> It is not really difficult to let an MN to reject rules sent by HA,=20 >> which in my view would be quite natural. This implies that HA must=20 >> follow the rules installed by MN until explicit acceptance has been=20 >> received from MN. >> Such procedure is very similar to an MN beahviour when initiating new = >> BU, where MN is not supposed to send any traffic before BU=20 >> confirmation. >> BTW, what is the numerical representation of "rough consensus"? I=20 >> assume is when majority is for, is it so? >> Yuri >> >> >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf=20 >> Of Hesham Soliman >> Sent: Thursday, May 28, 2009 12:07 PM >> To: mext >> Subject: [MEXT] Important considerations for directionality of flow=20 >> bindings >> >> Hi all, >> >> I've always been a fan of the IETF's tradition of rough concensus (as = >> opposed to voting). To me, this implies that you need to get your=20 >> point across and get other people to see that point of view. As=20 >> opposed to other organisations that require their members to vote and = >> end up with rigid political positions. >> >> The chairs asked us about the directionality question of the flows=20 >> bindings. >> On the charter question, I said that the charter doesn't need to=20 >> mention how a solution should work, but rather what problem needs to=20 >> be solved. >> Hence, as far as the charter is concerned, I'm fine with transferring = >> rules "between" the MN and HA without mentioning directions. >> >> Nevertheless, we still need to agree on identifying the requirement=20 >> for the solution. And when it comes to this, I'm strongly against=20 >> voting and I'll practice this by explaining in this email why I think = >> rules can not be transferred from the HA to the MN and that the only=20 >> direction that makes sense in MIP is MN->HA. I'll deliberately ignore = >> arguments like "some people want this" or "an SDO wants this". They=20 >> fall under the "meaningless words" >> category and I'm incapable of discussing them because they come with=20 >> voting attitudes. They all need to be justified if the WG wants to=20 >> have a technical _discussion_. >> >> Here are my reasons: >> >> 1. The HA does not know whether a CoA is tied to a certain access=20 >> technology. It is one thing for the HA to send a message saying=20 >> "forward port 80 traffic on a wifi link" (a policy) and a completely=20 >> different thing to say "forward port 80 traffic using CoA 3ffe::1" (a = >> rule). >> >> 2. You might argue that the HA can be told by the MN that 3ffe::1 is=20 >> tied to a wifi access, so what's the problem now? The problem is that = >> the HA has no idea about dynamic changes on that wifi link. It=20 >> doesn't know if it's congested, it doesn't know what application is=20 >> using port 80 (it doesn't have to be web traffic) or port 8000 for=20 >> that matter and doesn't even know if the AP of that wifi link works=20 >> at all. >> Finally, it >> doesn't know the user's policies or other admin policies for that MN. >> This type of information needs to be sent regularly because it=20 >> changes all the time and requires serious cross layer integration=20 >> including sometimes layer 8 integration! It's completely impractical. >> >> 3. If the HA installed rules in the MN, what happens if the MN wants=20 >> to change those rules. Say the wifi link went down, or the MN's wifi=20 >> interface went down and it wants to move that traffic to another=20 >> interface. Would the HA reject such move? Does the MN have to justify = >> to the HA why it needs to move traffic? Does that involve writing a=20 >> letter perhaps? >> If you say "well in that case, the HA should let the MN move the=20 >> traffic" >> then I'll ask you: what's the point of having the HA install this=20 >> stuff if it has no authority and how does it know the reason for the=20 >> MN's movement of the flow? >> The way to control how users do things is to incentivise them with=20 >> charging models and show them that things work better on certain=20 >> technologies, not by installing rules that can't be followed. It's a=20 >> broken mindset and we've known that it's broken for a long time. >> >> 4. Some people mentioned that the HA should be able to revoke flows=20 >> on the MN. I'm perfectly fine with that, just extend the binding=20 >> revocation draft to handle flows and the rest is pretty straight=20 >> forward. >> >> Finally, I'll indulge in a true story that happened to me a few years = >> ago when I found that my wifi link wasn't working in a hotel (no >> radio) >> and called the help desk. He insisted that the link was up an I=20 >> insisted that it wasn't. When I asked him to tell me how he knows the = >> link is up he said: I can ping the AP! Of course after another 5=20 >> minutes of trying to convince him that pinging the AP doesn't mean=20 >> the radio is actually working he sent someone to the hotel who in=20 >> turn realised that the radio was not working. >> For those people who want rules to be transferred from the HA to the=20 >> MN, please think of your HA as this help desk person, i.e. it has no=20 >> clue about what's happening at the other end. >> >> I hope this helps with the realisation that decisions can't be made=20 >> here based on voting and that there is little merit to transferring=20 >> rules from the HA to the MN. Policies can be transferred without any=20 >> problems, but not rules. >> >> Hesham >> >> >> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From hesham@elevatemobile.com Tue Jun 2 23:35:22 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CCF63A6403 for ; Tue, 2 Jun 2009 23:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.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 HiXRqsGHueuh for ; Tue, 2 Jun 2009 23:35:21 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id D09E73A6C93 for ; Tue, 2 Jun 2009 23:33:41 -0700 (PDT) Received: from [115.130.49.157] by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MBk2b-000367-Uw; Wed, 03 Jun 2009 16:33:38 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Wed, 03 Jun 2009 16:33:29 +1000 From: Hesham Soliman To: Yuri Ismailov , Julien Laganier Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flow bindings Thread-Index: Acnjf5QY2xs1llgPSQe1H1TTFmGKeAABB69gACRghU4= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext Subject: Re: [MEXT] Important considerations for directionality of flow bindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 06:35:22 -0000 >> How do you make your HA know that the address XYZ your MN just SLAAC'd at the >> starbucks downdown is assigned towards on a 54Mbs WiFi link? >> Are you driving back to home to configure appropriately your HA while the MN >> stays at starbucks? > > The key is that one may use (I definetly would) applciation level to > communicate any kind of parameters between HA and MN. I do not mean routing > rules. Basically anything else. If one finds that the fact of MN being > attached to 54Mbs WiFi link is useful information for HA, then there is > nothing preventing to send this information to HA without involving MIP. => So, in this statement you make the following assumptions: 1. That the MN knows what is useful for the HA to know 2. That it's useful to send information to the HA so it can respond back to the MN with the consequences of the information sent. In essence, the MN knows what link it is connected to, yet it sends that information to the HA so it can tell it what to do about it. Does that really make sense to you? Why? We really need to see a substantial list of benefits here because otherwise this is a complete waste of a RT between the MN and the HA. What could the HA possibly tell the MN that it doesn't already know?? > Next important thing, in my view, is that the logic generating this or that > set of routing rules whether implemented in MN or HA or both has nothing to do > with MIP. This logic is about how to choose an interface for a particular flow > and in theory may be delegated to a third party node (do not think this is a > good idea though). => This is orthogonal to the discussion about the directionality of rule transmission. Of course the logic is generated by upper layers but there is no relationship between the layer generating the information and the direction of information flow. The same layer exists at both ends. Hesham From pierrick.seite@orange-ftgroup.com Tue Jun 2 23:35:53 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC643A6359 for ; Tue, 2 Jun 2009 23:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35] 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 E41bK59FnXTA for ; Tue, 2 Jun 2009 23:35:52 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id BAFB03A6403 for ; Tue, 2 Jun 2009 23:35:51 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 08:35:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 08:35:50 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46219156F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <001c01c9e3a0$8441ff40$3e0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjoJvDfGImVKZyTsKYItDA95S/RwAc2LcA References: <843DA8228A1BA74CA31FB4E111A5C462191437@ftrdmel0.rd.francetelecom.fr> <001c01c9e3a0$8441ff40$3e0c7c0a@china.huawei.com> From: To: , X-OriginalArrivalTime: 03 Jun 2009 06:35:51.0516 (UTC) FILETIME=[89DCB9C0:01C9E415] Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 06:35:53 -0000 Hi Frank, We are not saying that policies must not be updated. Actually, we are = considering policies are quasi-static; I think it is the case for PCRF: = there is no need to update these policies every milliseconds. Basically, = we are saying there is no requirement for piggybacking MIP signalling to = transport policies because existing mechanisms can be reused, typically = 3GPP mechanism could be candidate. Hope that clarifies, BR, Pierrick=20 > -----Message d'origine----- > De=A0: Frank Xia [mailto:xiayangsong@huawei.com] > Envoy=E9=A0: mardi 2 juin 2009 18:38 > =C0=A0: Nicolas Montavont; SEITE Pierrick RD-RESA-REN > Cc=A0: mext@ietf.org > Objet=A0: Re: [MEXT] Important considerations for directionality of > flowbindings >=20 > Hi Nicolas and Pierrick >=20 > As for policy and rules which you think policy > is static while rules are dynamic, I don't think > I have the same understanding as you. >=20 > In 3GPP/TISPAN, PCRF ( Policy and Charging > Rules function entity) could enforce > PCC (Policy and Charging Control)dynamically. >=20 > There is not such a difference which you highlighted. >=20 > BR > Frank >=20 > ----- Original Message ----- > From: "Nicolas Montavont" > To: > Cc: > Sent: Tuesday, June 02, 2009 10:46 AM > Subject: Re: [MEXT] Important considerations for directionality of > flowbindings >=20 >=20 > Hi Pierrick, >=20 > On Jun 2, 2009, at 4:11 PM, wrote: >=20 > > > > Hi all, > > > > Please see inline comment. > > > > Regards, > > Pierrick > > > >> ________________________________________ > >> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la = part > de > >> Yuri Ismailov > >> Envoy=E9 : vendredi 29 mai 2009 09:35 > >> =C0 : Hesham Soliman; mext > >> Objet : Re: [MEXT] Important considerations for directionality of > >> flowbindings > >> > >> Hesham, > >> This is nice story and makes some sense for the discssion, however > some > >> details are ommited. In your adventure with the helpdesk, it (the > >> helpdesk) is a third party service and thus your conclusions make > sence. > >> Think of the situation when superior of a heldesk person will tell > >> him/her > >> to check access point in some room. Would it be the same reaction? = I > >> assume not. By that I mean that if, for example, I'll install home > agent > >> in my home network, I can make it know anything I want about MN, = and > >> more > >> intresting is that how I will do it, does not require any > >> standardization. > >> In other words, I'm superior of my HA. > >> This situation is not unthinkable, I personally believe that this = is > >> much > >> more efficient way of using HA fnctionality as opposed to big = service > >> providers who will have to fight with scalability and performance. > >> However, one does not exclude another. > >> Difference between policies and rules is a convertion step. > >> > >> > > > > > > The difference between policy and rules is not only a matter of > > conversion. A policy, is a static, or quasi-static, set of guidance = for > > the MN (e.g use access network X for application type A,...) while = a > rule > > update requires to be more dynamic. I mean: eventually a policy = could > be > > updated depending on network condition (e.g if X overloaded, use = access > > network Y for application type A,...) but a rule reacts on local > triggers > > (e.g. modification of the radio link quality) with a shorter period = of > > variation. So, IMHO, there is no requirement for updating policy on = a > > short period and out-of-band mechanism can be used (e.g. IEEE = 802.21 in > > push mode,...). >=20 > Fully agree! > This is why I do not support the exchange of rules from the HA to the > MN. Policies may be exchanged from the HA to the MN, but MIP is > definitely not the protocol to transport them. >=20 > Nicolas >=20 > > > > > > My 2 cents... > > > >> > >> Is there any reason to restrict where such convertion takes place? > True > >> that a HA does not know what is going on in the access network, on = the > >> other hand HA may know what is the network condition between HA and > >> correspondent node. Either of this information is important, if not > >> equally important. > >> It is not really difficult to let an MN to reject rules sent by HA, > >> which > >> in my view would be quite natural. This implies that HA must follow > the > >> rules installed by MN until explicit acceptance has been received = from > >> MN. > >> Such procedure is very similar to an MN beahviour when initiating = new > >> BU, > >> where MN is not supposed to send any traffic before BU = confirmation. > >> BTW, what is the numerical representation of "rough consensus"? I > assume > >> is when majority is for, is it so? > >> Yuri > >> > >> > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On = Behalf > Of > >> Hesham Soliman > >> Sent: Thursday, May 28, 2009 12:07 PM > >> To: mext > >> Subject: [MEXT] Important considerations for directionality of flow > >> bindings > >> > >> Hi all, > >> > >> I've always been a fan of the IETF's tradition of rough concensus = (as > >> opposed to voting). To me, this implies that you need to get your > point > >> across and get other people to see that point of view. As opposed = to > >> other organisations that require their members to vote and end up = with > >> rigid political positions. > >> > >> The chairs asked us about the directionality question of the flows > >> bindings. > >> On the charter question, I said that the charter doesn't need to > mention > >> how a solution should work, but rather what problem needs to be > solved. > >> Hence, as far as the charter is concerned, I'm fine with = transferring > >> rules "between" the MN and HA without mentioning directions. > >> > >> Nevertheless, we still need to agree on identifying the requirement > for > >> the solution. And when it comes to this, I'm strongly against = voting > and > >> I'll practice this by explaining in this email why I think rules = can > not > >> be transferred from the HA to the MN and that the only direction = that > >> makes sense in MIP is MN->HA. I'll deliberately ignore arguments = like > >> "some people want this" or "an SDO wants this". They fall under the > >> "meaningless words" > >> category and I'm incapable of discussing them because they come = with > >> voting attitudes. They all need to be justified if the WG wants to > have > >> a technical _discussion_. > >> > >> Here are my reasons: > >> > >> 1. The HA does not know whether a CoA is tied to a certain access > >> technology. It is one thing for the HA to send a message saying > "forward > >> port 80 traffic on a wifi link" (a policy) and a completely = different > >> thing to say "forward port 80 traffic using CoA 3ffe::1" (a rule). > >> > >> 2. You might argue that the HA can be told by the MN that 3ffe::1 = is > >> tied to a wifi access, so what's the problem now? The problem is = that > >> the HA has no idea about dynamic changes on that wifi link. It = doesn't > >> know if it's congested, it doesn't know what application is using = port > >> 80 (it doesn't have to be web traffic) or port 8000 for that matter > and > >> doesn't even know if the AP of that wifi link works at all. = Finally, > it > >> doesn't know the user's policies or other admin policies for that = MN. > >> This type of information needs to be sent regularly because it = changes > >> all the time and requires serious cross layer integration including > >> sometimes layer 8 integration! It's completely impractical. > >> > >> 3. If the HA installed rules in the MN, what happens if the MN = wants > to > >> change those rules. Say the wifi link went down, or the MN's wifi > >> interface went down and it wants to move that traffic to another > >> interface. Would the HA reject such move? Does the MN have to = justify > to > >> the HA why it needs to move traffic? Does that involve writing a > letter > >> perhaps? > >> If you say "well in that case, the HA should let the MN move the > >> traffic" > >> then I'll ask you: what's the point of having the HA install this > stuff > >> if it has no authority and how does it know the reason for the MN's > >> movement of the flow? > >> The way to control how users do things is to incentivise them with > >> charging models and show them that things work better on certain > >> technologies, not by installing rules that can't be followed. It's = a > >> broken mindset and we've known that it's broken for a long time. > >> > >> 4. Some people mentioned that the HA should be able to revoke flows = on > >> the MN. I'm perfectly fine with that, just extend the binding > revocation > >> draft to handle flows and the rest is pretty straight forward. > >> > >> Finally, I'll indulge in a true story that happened to me a few = years > >> ago when I found that my wifi link wasn't working in a hotel (no > radio) > >> and called the help desk. He insisted that the link was up an I > insisted > >> that it wasn't. When I asked him to tell me how he knows the link = is > up > >> he said: I can ping the AP! Of course after another 5 minutes of > trying > >> to convince him that pinging the AP doesn't mean the radio is = actually > >> working he sent someone to the hotel who in turn realised that the > radio > >> was not working. > >> For those people who want rules to be transferred from the HA to = the > MN, > >> please think of your HA as this help desk person, i.e. it has no = clue > >> about what's happening at the other end. > >> > >> I hope this helps with the realisation that decisions can't be made > here > >> based on voting and that there is little merit to transferring = rules > >> from the HA to the MN. Policies can be transferred without any > problems, > >> but not rules. > >> > >> Hesham > >> > >> > >> > >> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From hesham@elevatemobile.com Tue Jun 2 23:41:39 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 433243A691F for ; Tue, 2 Jun 2009 23:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.401 X-Spam-Level: X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 2BWSdCzHwtj6 for ; Tue, 2 Jun 2009 23:41:38 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id AD7B73A6358 for ; Tue, 2 Jun 2009 23:41:36 -0700 (PDT) Received: from [115.130.49.157] by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MBkA8-0007LO-Ge; Wed, 03 Jun 2009 16:41:28 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Wed, 03 Jun 2009 16:41:17 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwc= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 06:41:39 -0000 Yuri, It is just rules TRANSFER which is the matter of MIP. So where > is the logic when saying that MN to HA rules transfer is a practical > engineering and HA to MN is an academic interest? =3D> I think we've (I'm including myself) highlighted several reasons for why it makes little sense to transfer rules from HA to MN. Instead of rat-holin= g on theory Vs practice, you (or others advocating the other direction) need to come up with reasons for doing things this way. This way we can think like engineers about tradeoffs. Absent that, I don't see any point in having theory Vs practice high level discussions, which will lead nowhere. Hesham >=20 > Regards > Yuri >=20 > -----Original Message----- > From: Nicolas Montavont [mailto:ietf@montavont.net] > Sent: Tuesday, June 02, 2009 5:47 PM > To: pierrick.seite@orange-ftgroup.com > Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of > flowbindings >=20 > Hi Pierrick, >=20 > On Jun 2, 2009, at 4:11 PM, wrote: >=20 >>=20 >> Hi all, >>=20 >> Please see inline comment. >>=20 >> Regards, >> Pierrick >>=20 >>> ________________________________________ >>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part >>> de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 : Hesham >>> Soliman; mext Objet : Re: [MEXT] Important considerations for >>> directionality of flowbindings >>>=20 >>> Hesham, >>> This is nice story and makes some sense for the discssion, however >>> some details are ommited. In your adventure with the helpdesk, it >>> (the >>> helpdesk) is a third party service and thus your conclusions make >>> sence. >>> Think of the situation when superior of a heldesk person will tell >>> him/her to check access point in some room. Would it be the same >>> reaction? I assume not. By that I mean that if, for example, I'll >>> install home agent in my home network, I can make it know anything I >>> want about MN, and more intresting is that how I will do it, does not >>> require any standardization. >>> In other words, I'm superior of my HA. >>> This situation is not unthinkable, I personally believe that this is >>> much more efficient way of using HA fnctionality as opposed to big >>> service providers who will have to fight with scalability and >>> performance. >>> However, one does not exclude another. >>> Difference between policies and rules is a convertion step. >>>=20 >>>=20 >>=20 >>=20 >> The difference between policy and rules is not only a matter of >> conversion. A policy, is a static, or quasi-static, set of guidance >> for the MN (e.g use access network X for application type A,...) while >> a rule update requires to be more dynamic. I mean: eventually a policy >> could be updated depending on network condition (e.g if X overloaded, >> use access network Y for application type A,...) but a rule reacts on >> local triggers (e.g. modification of the radio link >> quality) with a shorter period of variation. So, IMHO, there is no >> requirement for updating policy on a short period and out-of-band >> mechanism can be used (e.g. IEEE 802.21 in push mode,...). >=20 > Fully agree! > This is why I do not support the exchange of rules from the HA to the MN. > Policies may be exchanged from the HA to the MN, but MIP is definitely no= t the > protocol to transport them. >=20 > Nicolas >=20 >>=20 >>=20 >> My 2 cents... >>=20 >>>=20 >>> Is there any reason to restrict where such convertion takes place? >>> True >>> that a HA does not know what is going on in the access network, on >>> the other hand HA may know what is the network condition between HA >>> and correspondent node. Either of this information is important, if >>> not equally important. >>> It is not really difficult to let an MN to reject rules sent by HA, >>> which in my view would be quite natural. This implies that HA must >>> follow the rules installed by MN until explicit acceptance has been >>> received from MN. >>> Such procedure is very similar to an MN beahviour when initiating new >>> BU, where MN is not supposed to send any traffic before BU >>> confirmation. >>> BTW, what is the numerical representation of "rough consensus"? I >>> assume is when majority is for, is it so? >>> Yuri >>>=20 >>>=20 >>> -----Original Message----- >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf >>> Of Hesham Soliman >>> Sent: Thursday, May 28, 2009 12:07 PM >>> To: mext >>> Subject: [MEXT] Important considerations for directionality of flow >>> bindings >>>=20 >>> Hi all, >>>=20 >>> I've always been a fan of the IETF's tradition of rough concensus (as >>> opposed to voting). To me, this implies that you need to get your >>> point across and get other people to see that point of view. As >>> opposed to other organisations that require their members to vote and >>> end up with rigid political positions. >>>=20 >>> The chairs asked us about the directionality question of the flows >>> bindings. >>> On the charter question, I said that the charter doesn't need to >>> mention how a solution should work, but rather what problem needs to >>> be solved. >>> Hence, as far as the charter is concerned, I'm fine with transferring >>> rules "between" the MN and HA without mentioning directions. >>>=20 >>> Nevertheless, we still need to agree on identifying the requirement >>> for the solution. And when it comes to this, I'm strongly against >>> voting and I'll practice this by explaining in this email why I think >>> rules can not be transferred from the HA to the MN and that the only >>> direction that makes sense in MIP is MN->HA. I'll deliberately ignore >>> arguments like "some people want this" or "an SDO wants this". They >>> fall under the "meaningless words" >>> category and I'm incapable of discussing them because they come with >>> voting attitudes. They all need to be justified if the WG wants to >>> have a technical _discussion_. >>>=20 >>> Here are my reasons: >>>=20 >>> 1. The HA does not know whether a CoA is tied to a certain access >>> technology. It is one thing for the HA to send a message saying >>> "forward port 80 traffic on a wifi link" (a policy) and a completely >>> different thing to say "forward port 80 traffic using CoA 3ffe::1" (a >>> rule). >>>=20 >>> 2. You might argue that the HA can be told by the MN that 3ffe::1 is >>> tied to a wifi access, so what's the problem now? The problem is that >>> the HA has no idea about dynamic changes on that wifi link. It >>> doesn't know if it's congested, it doesn't know what application is >>> using port 80 (it doesn't have to be web traffic) or port 8000 for >>> that matter and doesn't even know if the AP of that wifi link works >>> at all. >>> Finally, it >>> doesn't know the user's policies or other admin policies for that MN. >>> This type of information needs to be sent regularly because it >>> changes all the time and requires serious cross layer integration >>> including sometimes layer 8 integration! It's completely impractical. >>>=20 >>> 3. If the HA installed rules in the MN, what happens if the MN wants >>> to change those rules. Say the wifi link went down, or the MN's wifi >>> interface went down and it wants to move that traffic to another >>> interface. Would the HA reject such move? Does the MN have to justify >>> to the HA why it needs to move traffic? Does that involve writing a >>> letter perhaps? >>> If you say "well in that case, the HA should let the MN move the >>> traffic" >>> then I'll ask you: what's the point of having the HA install this >>> stuff if it has no authority and how does it know the reason for the >>> MN's movement of the flow? >>> The way to control how users do things is to incentivise them with >>> charging models and show them that things work better on certain >>> technologies, not by installing rules that can't be followed. It's a >>> broken mindset and we've known that it's broken for a long time. >>>=20 >>> 4. Some people mentioned that the HA should be able to revoke flows >>> on the MN. I'm perfectly fine with that, just extend the binding >>> revocation draft to handle flows and the rest is pretty straight >>> forward. >>>=20 >>> Finally, I'll indulge in a true story that happened to me a few years >>> ago when I found that my wifi link wasn't working in a hotel (no >>> radio) >>> and called the help desk. He insisted that the link was up an I >>> insisted that it wasn't. When I asked him to tell me how he knows the >>> link is up he said: I can ping the AP! Of course after another 5 >>> minutes of trying to convince him that pinging the AP doesn't mean >>> the radio is actually working he sent someone to the hotel who in >>> turn realised that the radio was not working. >>> For those people who want rules to be transferred from the HA to the >>> MN, please think of your HA as this help desk person, i.e. it has no >>> clue about what's happening at the other end. >>>=20 >>> I hope this helps with the realisation that decisions can't be made >>> here based on voting and that there is little merit to transferring >>> rules from the HA to the MN. Policies can be transferred without any >>> problems, but not rules. >>>=20 >>> Hesham >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >=20 From yuri.ismailov@ericsson.com Tue Jun 2 23:47:39 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23E053A6A35 for ; Tue, 2 Jun 2009 23:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.749 X-Spam-Level: X-Spam-Status: No, score=-6.749 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 ueYNDOF0AzsA for ; Tue, 2 Jun 2009 23:47:38 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9FA4E3A6A17 for ; Tue, 2 Jun 2009 23:47:37 -0700 (PDT) X-AuditID: c1b4fb3e-b7b4bae00000395e-33-4a261c89a75c Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 7E.14.14686.98C162A4; Wed, 3 Jun 2009 08:47:37 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jun 2009 08:46:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 08:46:31 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flow bindings Thread-Index: Acnjf5QY2xs1llgPSQe1H1TTFmGKeAABB69gACRghU4AAD9dQA== References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Julien Laganier" X-OriginalArrivalTime: 03 Jun 2009 06:46:31.0870 (UTC) FILETIME=[078AFDE0:01C9E417] X-Brightmail-Tracker: AAAAAA== Cc: mext Subject: Re: [MEXT] Important considerations for directionality of flow bindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 06:47:39 -0000 As I just wrote events may take place anywhere in the network and it may be the case that HA knows about that but not MN. If HA has relevant information about MN parameters it can act upon event arrival, otherwise not. These to things are complementary and I have the rough consesus with myself that MN has a priority in decision, but not accepting hints is a limitation. Moreover, hints may come from any other node in the network, not necessarily from HA. /Yuri -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Wednesday, June 03, 2009 8:33 AM To: Yuri Ismailov; Julien Laganier Cc: mext Subject: Re: [MEXT] Important considerations for directionality of flow bindings >> How do you make your HA know that the address XYZ your MN just=20 >> SLAAC'd at the starbucks downdown is assigned towards on a 54Mbs WiFi link? >> Are you driving back to home to configure appropriately your HA while >> the MN stays at starbucks? >=20 > The key is that one may use (I definetly would) applciation level to=20 > communicate any kind of parameters between HA and MN. I do not mean=20 > routing rules. Basically anything else. If one finds that the fact of=20 > MN being attached to 54Mbs WiFi link is useful information for HA,=20 > then there is nothing preventing to send this information to HA without involving MIP. =3D> So, in this statement you make the following assumptions: 1. That the MN knows what is useful for the HA to know 2. That it's useful to send information to the HA so it can respond back to the MN with the consequences of the information sent. In essence, the MN knows what link it is connected to, yet it sends that information to the HA so it can tell it what to do about it. Does that really make sense to you? Why? We really need to see a substantial list of benefits here because otherwise this is a complete waste of a RT between the MN and the HA. What could the HA possibly tell the MN that it doesn't already know?? > Next important thing, in my view, is that the logic generating this or > that set of routing rules whether implemented in MN or HA or both has=20 > nothing to do with MIP. This logic is about how to choose an interface > for a particular flow and in theory may be delegated to a third party=20 > node (do not think this is a good idea though). =3D> This is orthogonal to the discussion about the directionality of = rule transmission. Of course the logic is generated by upper layers but there is no relationship between the layer generating the information and the direction of information flow. The same layer exists at both ends. Hesham From yuri.ismailov@ericsson.com Wed Jun 3 00:00:48 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8818F3A691F for ; Wed, 3 Jun 2009 00:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.582 X-Spam-Level: X-Spam-Status: No, score=-7.582 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 UACFCUByuFlq for ; Wed, 3 Jun 2009 00:00:47 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6AD503A6877 for ; Wed, 3 Jun 2009 00:00:46 -0700 (PDT) X-AuditID: c1b4fb3c-b7b14ae0000039d7-c0-4a261f9e48b6 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id C2.2B.14807.E9F162A4; Wed, 3 Jun 2009 09:00:46 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jun 2009 09:00:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 09:00:33 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwA== References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 03 Jun 2009 07:00:34.0479 (UTC) FILETIME=[FDC6EBF0:01C9E418] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 07:00:48 -0000 Hesham, "Academic interest" is not my argument and I agree that this kind of = discussion will take us nowhere. You withdrew this statement from the = context. Some examples: - network condition towards CN(s) - the sum of number of hops between MN -> HA and HA -> CN - Access provider (any access, not necessarily wireless) who offeres HA = services preferences change - Change of the access provider traffic to another backbone provider due = to the time of the day. - Traffic condition on HA interface, which accepts traffic from MN if MN = sends on some particular local interface Pretty much sure that there are more examples and I encourage to think = about those not from MN point of view but rather from the HA service = provider. /yuri -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Wednesday, June 03, 2009 8:41 AM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings Yuri, It is just rules TRANSFER which is the matter of MIP. So where > is the logic when saying that MN to HA rules transfer is a practical=20 > engineering and HA to MN is an academic interest? =3D> I think we've (I'm including myself) highlighted several reasons = for why it makes little sense to transfer rules from HA to MN. Instead = of rat-holing on theory Vs practice, you (or others advocating the other = direction) need to come up with reasons for doing things this way. This = way we can think like engineers about tradeoffs. Absent that, I don't see any point in having theory Vs practice high = level discussions, which will lead nowhere. Hesham >=20 > Regards > Yuri >=20 > -----Original Message----- > From: Nicolas Montavont [mailto:ietf@montavont.net] > Sent: Tuesday, June 02, 2009 5:47 PM > To: pierrick.seite@orange-ftgroup.com > Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of=20 > flowbindings >=20 > Hi Pierrick, >=20 > On Jun 2, 2009, at 4:11 PM, wrote: >=20 >>=20 >> Hi all, >>=20 >> Please see inline comment. >>=20 >> Regards, >> Pierrick >>=20 >>> ________________________________________ >>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part = >>> de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 : Hesham=20 >>> Soliman; mext Objet : Re: [MEXT] Important considerations for=20 >>> directionality of flowbindings >>>=20 >>> Hesham, >>> This is nice story and makes some sense for the discssion, however=20 >>> some details are ommited. In your adventure with the helpdesk, it=20 >>> (the >>> helpdesk) is a third party service and thus your conclusions make=20 >>> sence. >>> Think of the situation when superior of a heldesk person will tell=20 >>> him/her to check access point in some room. Would it be the same=20 >>> reaction? I assume not. By that I mean that if, for example, I'll=20 >>> install home agent in my home network, I can make it know anything I = >>> want about MN, and more intresting is that how I will do it, does=20 >>> not require any standardization. >>> In other words, I'm superior of my HA. >>> This situation is not unthinkable, I personally believe that this is = >>> much more efficient way of using HA fnctionality as opposed to big=20 >>> service providers who will have to fight with scalability and=20 >>> performance. >>> However, one does not exclude another. >>> Difference between policies and rules is a convertion step. >>>=20 >>>=20 >>=20 >>=20 >> The difference between policy and rules is not only a matter of=20 >> conversion. A policy, is a static, or quasi-static, set of guidance=20 >> for the MN (e.g use access network X for application type A,...)=20 >> while a rule update requires to be more dynamic. I mean: eventually a = >> policy could be updated depending on network condition (e.g if X=20 >> overloaded, use access network Y for application type A,...) but a=20 >> rule reacts on local triggers (e.g. modification of the radio link >> quality) with a shorter period of variation. So, IMHO, there is no=20 >> requirement for updating policy on a short period and out-of-band=20 >> mechanism can be used (e.g. IEEE 802.21 in push mode,...). >=20 > Fully agree! > This is why I do not support the exchange of rules from the HA to the = MN. > Policies may be exchanged from the HA to the MN, but MIP is definitely = > not the protocol to transport them. >=20 > Nicolas >=20 >>=20 >>=20 >> My 2 cents... >>=20 >>>=20 >>> Is there any reason to restrict where such convertion takes place? >>> True >>> that a HA does not know what is going on in the access network, on=20 >>> the other hand HA may know what is the network condition between HA=20 >>> and correspondent node. Either of this information is important, if=20 >>> not equally important. >>> It is not really difficult to let an MN to reject rules sent by HA,=20 >>> which in my view would be quite natural. This implies that HA must=20 >>> follow the rules installed by MN until explicit acceptance has been=20 >>> received from MN. >>> Such procedure is very similar to an MN beahviour when initiating=20 >>> new BU, where MN is not supposed to send any traffic before BU=20 >>> confirmation. >>> BTW, what is the numerical representation of "rough consensus"? I=20 >>> assume is when majority is for, is it so? >>> Yuri >>>=20 >>>=20 >>> -----Original Message----- >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf = >>> Of Hesham Soliman >>> Sent: Thursday, May 28, 2009 12:07 PM >>> To: mext >>> Subject: [MEXT] Important considerations for directionality of flow=20 >>> bindings >>>=20 >>> Hi all, >>>=20 >>> I've always been a fan of the IETF's tradition of rough concensus=20 >>> (as opposed to voting). To me, this implies that you need to get=20 >>> your point across and get other people to see that point of view. As = >>> opposed to other organisations that require their members to vote=20 >>> and end up with rigid political positions. >>>=20 >>> The chairs asked us about the directionality question of the flows=20 >>> bindings. >>> On the charter question, I said that the charter doesn't need to=20 >>> mention how a solution should work, but rather what problem needs to = >>> be solved. >>> Hence, as far as the charter is concerned, I'm fine with=20 >>> transferring rules "between" the MN and HA without mentioning = directions. >>>=20 >>> Nevertheless, we still need to agree on identifying the requirement=20 >>> for the solution. And when it comes to this, I'm strongly against=20 >>> voting and I'll practice this by explaining in this email why I=20 >>> think rules can not be transferred from the HA to the MN and that=20 >>> the only direction that makes sense in MIP is MN->HA. I'll=20 >>> deliberately ignore arguments like "some people want this" or "an=20 >>> SDO wants this". They fall under the "meaningless words" >>> category and I'm incapable of discussing them because they come with = >>> voting attitudes. They all need to be justified if the WG wants to=20 >>> have a technical _discussion_. >>>=20 >>> Here are my reasons: >>>=20 >>> 1. The HA does not know whether a CoA is tied to a certain access=20 >>> technology. It is one thing for the HA to send a message saying=20 >>> "forward port 80 traffic on a wifi link" (a policy) and a completely = >>> different thing to say "forward port 80 traffic using CoA 3ffe::1"=20 >>> (a rule). >>>=20 >>> 2. You might argue that the HA can be told by the MN that 3ffe::1 is = >>> tied to a wifi access, so what's the problem now? The problem is=20 >>> that the HA has no idea about dynamic changes on that wifi link. It=20 >>> doesn't know if it's congested, it doesn't know what application is=20 >>> using port 80 (it doesn't have to be web traffic) or port 8000 for=20 >>> that matter and doesn't even know if the AP of that wifi link works=20 >>> at all. >>> Finally, it >>> doesn't know the user's policies or other admin policies for that = MN. >>> This type of information needs to be sent regularly because it=20 >>> changes all the time and requires serious cross layer integration=20 >>> including sometimes layer 8 integration! It's completely = impractical. >>>=20 >>> 3. If the HA installed rules in the MN, what happens if the MN wants = >>> to change those rules. Say the wifi link went down, or the MN's wifi = >>> interface went down and it wants to move that traffic to another=20 >>> interface. Would the HA reject such move? Does the MN have to=20 >>> justify to the HA why it needs to move traffic? Does that involve=20 >>> writing a letter perhaps? >>> If you say "well in that case, the HA should let the MN move the=20 >>> traffic" >>> then I'll ask you: what's the point of having the HA install this=20 >>> stuff if it has no authority and how does it know the reason for the = >>> MN's movement of the flow? >>> The way to control how users do things is to incentivise them with=20 >>> charging models and show them that things work better on certain=20 >>> technologies, not by installing rules that can't be followed. It's a = >>> broken mindset and we've known that it's broken for a long time. >>>=20 >>> 4. Some people mentioned that the HA should be able to revoke flows=20 >>> on the MN. I'm perfectly fine with that, just extend the binding=20 >>> revocation draft to handle flows and the rest is pretty straight=20 >>> forward. >>>=20 >>> Finally, I'll indulge in a true story that happened to me a few=20 >>> years ago when I found that my wifi link wasn't working in a hotel=20 >>> (no >>> radio) >>> and called the help desk. He insisted that the link was up an I=20 >>> insisted that it wasn't. When I asked him to tell me how he knows=20 >>> the link is up he said: I can ping the AP! Of course after another 5 = >>> minutes of trying to convince him that pinging the AP doesn't mean=20 >>> the radio is actually working he sent someone to the hotel who in=20 >>> turn realised that the radio was not working. >>> For those people who want rules to be transferred from the HA to the = >>> MN, please think of your HA as this help desk person, i.e. it has no = >>> clue about what's happening at the other end. >>>=20 >>> I hope this helps with the realisation that decisions can't be made=20 >>> here based on voting and that there is little merit to transferring=20 >>> rules from the HA to the MN. Policies can be transferred without any = >>> problems, but not rules. >>>=20 >>> Hesham >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >=20 From hesham@elevatemobile.com Wed Jun 3 00:12:50 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40A1E3A6A3D for ; Wed, 3 Jun 2009 00:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 5Qe2rgCI+Xrk for ; Wed, 3 Jun 2009 00:12:48 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 68C883A6A25 for ; Wed, 3 Jun 2009 00:12:47 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MBkeM-0005Ps-FK; Wed, 03 Jun 2009 17:12:39 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Wed, 03 Jun 2009 17:12:33 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4Usm In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 07:12:50 -0000 Yuri,=20 Thanks for progressing the discussion. Comments inline >=20 > - network condition towards CN(s) > - the sum of number of hops between MN -> HA and HA -> CN > - Access provider (any access, not necessarily wireless) who offeres HA > services preferences change > - Change of the access provider traffic to another backbone provider due = to > the time of the day. > - Traffic condition on HA interface, which accepts traffic from MN if MN = sends > on some particular local interface =3D> I'm trying to understand what you mean above. These are all scenarios, the question is: What is the benefit for the HA to transfer rules? The HA will not know the path between the MN and CN more than either node does. So I don't understand what _benefits_ you see here. Hesham >=20 > Pretty much sure that there are more examples and I encourage to think ab= out > those not from MN point of view but rather from the HA service provider. >=20 > /yuri >=20 >=20 >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Wednesday, June 03, 2009 8:41 AM > To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of > flowbindings >=20 > Yuri, >=20 > It is just rules TRANSFER which is the matter of MIP. So where >> is the logic when saying that MN to HA rules transfer is a practical >> engineering and HA to MN is an academic interest? >=20 > =3D> I think we've (I'm including myself) highlighted several reasons for w= hy it > makes little sense to transfer rules from HA to MN. Instead of rat-holing= on > theory Vs practice, you (or others advocating the other direction) need t= o > come up with reasons for doing things this way. This way we can think lik= e > engineers about tradeoffs. > Absent that, I don't see any point in having theory Vs practice high leve= l > discussions, which will lead nowhere. >=20 > Hesham >=20 >=20 >>=20 >> Regards >> Yuri >>=20 >> -----Original Message----- >> From: Nicolas Montavont [mailto:ietf@montavont.net] >> Sent: Tuesday, June 02, 2009 5:47 PM >> To: pierrick.seite@orange-ftgroup.com >> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of >> flowbindings >>=20 >> Hi Pierrick, >>=20 >> On Jun 2, 2009, at 4:11 PM, wrote: >>=20 >>>=20 >>> Hi all, >>>=20 >>> Please see inline comment. >>>=20 >>> Regards, >>> Pierrick >>>=20 >>>> ________________________________________ >>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part >>>> de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 : Hesham >>>> Soliman; mext Objet : Re: [MEXT] Important considerations for >>>> directionality of flowbindings >>>>=20 >>>> Hesham, >>>> This is nice story and makes some sense for the discssion, however >>>> some details are ommited. In your adventure with the helpdesk, it >>>> (the >>>> helpdesk) is a third party service and thus your conclusions make >>>> sence. >>>> Think of the situation when superior of a heldesk person will tell >>>> him/her to check access point in some room. Would it be the same >>>> reaction? I assume not. By that I mean that if, for example, I'll >>>> install home agent in my home network, I can make it know anything I >>>> want about MN, and more intresting is that how I will do it, does >>>> not require any standardization. >>>> In other words, I'm superior of my HA. >>>> This situation is not unthinkable, I personally believe that this is >>>> much more efficient way of using HA fnctionality as opposed to big >>>> service providers who will have to fight with scalability and >>>> performance. >>>> However, one does not exclude another. >>>> Difference between policies and rules is a convertion step. >>>>=20 >>>>=20 >>>=20 >>>=20 >>> The difference between policy and rules is not only a matter of >>> conversion. A policy, is a static, or quasi-static, set of guidance >>> for the MN (e.g use access network X for application type A,...) >>> while a rule update requires to be more dynamic. I mean: eventually a >>> policy could be updated depending on network condition (e.g if X >>> overloaded, use access network Y for application type A,...) but a >>> rule reacts on local triggers (e.g. modification of the radio link >>> quality) with a shorter period of variation. So, IMHO, there is no >>> requirement for updating policy on a short period and out-of-band >>> mechanism can be used (e.g. IEEE 802.21 in push mode,...). >>=20 >> Fully agree! >> This is why I do not support the exchange of rules from the HA to the MN= . >> Policies may be exchanged from the HA to the MN, but MIP is definitely >> not the protocol to transport them. >>=20 >> Nicolas >>=20 >>>=20 >>>=20 >>> My 2 cents... >>>=20 >>>>=20 >>>> Is there any reason to restrict where such convertion takes place? >>>> True >>>> that a HA does not know what is going on in the access network, on >>>> the other hand HA may know what is the network condition between HA >>>> and correspondent node. Either of this information is important, if >>>> not equally important. >>>> It is not really difficult to let an MN to reject rules sent by HA, >>>> which in my view would be quite natural. This implies that HA must >>>> follow the rules installed by MN until explicit acceptance has been >>>> received from MN. >>>> Such procedure is very similar to an MN beahviour when initiating >>>> new BU, where MN is not supposed to send any traffic before BU >>>> confirmation. >>>> BTW, what is the numerical representation of "rough consensus"? I >>>> assume is when majority is for, is it so? >>>> Yuri >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf >>>> Of Hesham Soliman >>>> Sent: Thursday, May 28, 2009 12:07 PM >>>> To: mext >>>> Subject: [MEXT] Important considerations for directionality of flow >>>> bindings >>>>=20 >>>> Hi all, >>>>=20 >>>> I've always been a fan of the IETF's tradition of rough concensus >>>> (as opposed to voting). To me, this implies that you need to get >>>> your point across and get other people to see that point of view. As >>>> opposed to other organisations that require their members to vote >>>> and end up with rigid political positions. >>>>=20 >>>> The chairs asked us about the directionality question of the flows >>>> bindings. >>>> On the charter question, I said that the charter doesn't need to >>>> mention how a solution should work, but rather what problem needs to >>>> be solved. >>>> Hence, as far as the charter is concerned, I'm fine with >>>> transferring rules "between" the MN and HA without mentioning directio= ns. >>>>=20 >>>> Nevertheless, we still need to agree on identifying the requirement >>>> for the solution. And when it comes to this, I'm strongly against >>>> voting and I'll practice this by explaining in this email why I >>>> think rules can not be transferred from the HA to the MN and that >>>> the only direction that makes sense in MIP is MN->HA. I'll >>>> deliberately ignore arguments like "some people want this" or "an >>>> SDO wants this". They fall under the "meaningless words" >>>> category and I'm incapable of discussing them because they come with >>>> voting attitudes. They all need to be justified if the WG wants to >>>> have a technical _discussion_. >>>>=20 >>>> Here are my reasons: >>>>=20 >>>> 1. The HA does not know whether a CoA is tied to a certain access >>>> technology. It is one thing for the HA to send a message saying >>>> "forward port 80 traffic on a wifi link" (a policy) and a completely >>>> different thing to say "forward port 80 traffic using CoA 3ffe::1" >>>> (a rule). >>>>=20 >>>> 2. You might argue that the HA can be told by the MN that 3ffe::1 is >>>> tied to a wifi access, so what's the problem now? The problem is >>>> that the HA has no idea about dynamic changes on that wifi link. It >>>> doesn't know if it's congested, it doesn't know what application is >>>> using port 80 (it doesn't have to be web traffic) or port 8000 for >>>> that matter and doesn't even know if the AP of that wifi link works >>>> at all. >>>> Finally, it >>>> doesn't know the user's policies or other admin policies for that MN. >>>> This type of information needs to be sent regularly because it >>>> changes all the time and requires serious cross layer integration >>>> including sometimes layer 8 integration! It's completely impractical. >>>>=20 >>>> 3. If the HA installed rules in the MN, what happens if the MN wants >>>> to change those rules. Say the wifi link went down, or the MN's wifi >>>> interface went down and it wants to move that traffic to another >>>> interface. Would the HA reject such move? Does the MN have to >>>> justify to the HA why it needs to move traffic? Does that involve >>>> writing a letter perhaps? >>>> If you say "well in that case, the HA should let the MN move the >>>> traffic" >>>> then I'll ask you: what's the point of having the HA install this >>>> stuff if it has no authority and how does it know the reason for the >>>> MN's movement of the flow? >>>> The way to control how users do things is to incentivise them with >>>> charging models and show them that things work better on certain >>>> technologies, not by installing rules that can't be followed. It's a >>>> broken mindset and we've known that it's broken for a long time. >>>>=20 >>>> 4. Some people mentioned that the HA should be able to revoke flows >>>> on the MN. I'm perfectly fine with that, just extend the binding >>>> revocation draft to handle flows and the rest is pretty straight >>>> forward. >>>>=20 >>>> Finally, I'll indulge in a true story that happened to me a few >>>> years ago when I found that my wifi link wasn't working in a hotel >>>> (no >>>> radio) >>>> and called the help desk. He insisted that the link was up an I >>>> insisted that it wasn't. When I asked him to tell me how he knows >>>> the link is up he said: I can ping the AP! Of course after another 5 >>>> minutes of trying to convince him that pinging the AP doesn't mean >>>> the radio is actually working he sent someone to the hotel who in >>>> turn realised that the radio was not working. >>>> For those people who want rules to be transferred from the HA to the >>>> MN, please think of your HA as this help desk person, i.e. it has no >>>> clue about what's happening at the other end. >>>>=20 >>>> I hope this helps with the realisation that decisions can't be made >>>> here based on voting and that there is little merit to transferring >>>> rules from the HA to the MN. Policies can be transferred without any >>>> problems, but not rules. >>>>=20 >>>> Hesham >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>=20 >=20 >=20 From tsirtsis@googlemail.com Wed Jun 3 00:17:54 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE6C43A6A3D for ; Wed, 3 Jun 2009 00:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2] 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 0lutlK6WV2na for ; Wed, 3 Jun 2009 00:17:52 -0700 (PDT) Received: from mail-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by core3.amsl.com (Postfix) with ESMTP id AE61F3A6A25 for ; Wed, 3 Jun 2009 00:17:51 -0700 (PDT) Received: by bwz22 with SMTP id 22so8473058bwz.37 for ; Wed, 03 Jun 2009 00:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sgZnU/AqBk7IlJakyU+2uZB8CI3S+BJoSwUv6wYnkL0=; b=ZPxlBF3LZxsCaCh2yanxLQFPLk7k67FWXViVR/7c4uS8ZJ6cAS6TtlfJIioL4a6j4K IHmP1vbIqMJdpdz8EQcv3/s/l5vlrRs6cnNE8fW580KTPO3rrcl7L4qDjWJwJ9aBzRqO +t7MrCFFMFm783ophCJV3ok3f2gi93sE78eiA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QoH8DbiXAqvlVpKcRu1C9sNM0b1Eff70R2DLpcAbDToPX99GI4icrD4/WOjT/brCKt 3sN2O8ox9PxGEq690/ynCuU9HZzzJGPISEDTToNcn/bvofs4E8R+3sMWgiA0wV+/Ee+w bOS0nK8zLVrccGppucGBnmVjQW9LxGlEcMTRQ= MIME-Version: 1.0 Received: by 10.223.115.12 with SMTP id g12mr229631faq.92.1244013470577; Wed, 03 Jun 2009 00:17:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jun 2009 08:17:49 +0100 Message-ID: From: George Tsirtsis To: Yuri Ismailov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 07:17:54 -0000 Yuri, Since you are working for a vendor to cellular operators it should be trivial for you to check what the bottlenecks in cellular and other wireless networks are. In cellular, by far the biggest bottleneck is the wireless link i.e., the airlink between the mobile and the base station (BS) / access point (AP). The next bottleneck is the backhaul link connecting the BS/AP to the aggregation router/switch depending on RAN architecture. These two links are simply too expensive to overdimention; the former due to spectrum cost/constraints, and the latter due to the high cost/volume of last-mile wires required to go to all the BS/AP. In all networks, technologies, and deployments I have been involved with, the rest of the network is considered pretty much to be overdimentioned. This is why all the conditions to which you claim the HA may have better view of (even if one considers the HA to somehow know the condition of the whole network, which of course is nonsense), are in any case not relevant in practice. And they are certainly not relevant to the uplink traffic sent by the mobile over the first 2 links, which are also the only relevant bottlenecks in the system. George On Wed, Jun 3, 2009 at 8:00 AM, Yuri Ismailov wrote: > Hesham, > "Academic interest" is not my argument and I agree that this kind of disc= ussion will take us nowhere. You withdrew this statement from the context. > Some examples: > > - network condition towards CN(s) > - the sum of number of hops between MN -> HA and HA -> CN > - Access provider (any access, not necessarily wireless) who offeres HA s= ervices preferences change > - Change of the access provider traffic to another backbone provider due = to the time of the day. > - Traffic condition on HA interface, which accepts traffic from MN if MN = sends on some particular local interface > > Pretty much sure that there are more examples and I encourage to think ab= out those not from MN point of view but rather from the HA service provider= . > > /yuri > > > > > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Wednesday, June 03, 2009 8:41 AM > To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of flowbi= ndings > > Yuri, > > =C2=A0It is just rules TRANSFER which is the matter of MIP. So where >> is the logic when saying that MN to HA rules transfer is a practical >> engineering and HA to MN is an academic interest? > > =3D> I think we've (I'm including myself) highlighted several reasons for= why it makes little sense to transfer rules from HA to MN. Instead of rat-= holing on theory Vs practice, you (or others advocating the other direction= ) need to come up with reasons for doing things this way. This way we can t= hink like engineers about tradeoffs. > Absent that, I don't see any point in having theory Vs practice high leve= l discussions, which will lead nowhere. > > Hesham > > >> >> Regards >> Yuri >> >> -----Original Message----- >> From: Nicolas Montavont [mailto:ietf@montavont.net] >> Sent: Tuesday, June 02, 2009 5:47 PM >> To: pierrick.seite@orange-ftgroup.com >> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of >> flowbindings >> >> Hi Pierrick, >> >> On Jun 2, 2009, at 4:11 PM, wrote: >> >>> >>> Hi all, >>> >>> Please see inline comment. >>> >>> Regards, >>> Pierrick >>> >>>> ________________________________________ >>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part >>>> de Yuri Ismailov Envoy=C3=A9 : vendredi 29 mai 2009 09:35 =C3=80 : Hes= ham >>>> Soliman; mext Objet : Re: [MEXT] Important considerations for >>>> directionality of flowbindings >>>> >>>> Hesham, >>>> This is nice story and makes some sense for the discssion, however >>>> some details are ommited. In your adventure with the helpdesk, it >>>> (the >>>> helpdesk) is a third party service and thus your conclusions make >>>> sence. >>>> Think of the situation when superior of a heldesk person will tell >>>> him/her to check access point in some room. Would it be the same >>>> reaction? I assume not. By that I mean that if, for example, I'll >>>> install home agent in my home network, I can make it know anything I >>>> want about MN, and more intresting is that how I will do it, does >>>> not require any standardization. >>>> In other words, I'm superior of my HA. >>>> This situation is not unthinkable, I personally believe that this is >>>> much more efficient way of using HA fnctionality as opposed to big >>>> service providers who will have to fight with scalability and >>>> performance. >>>> However, one does not exclude another. >>>> Difference between policies and rules is a convertion step. >>>> >>>> >>> >>> >>> The difference between policy and rules is not only a matter of >>> conversion. A policy, is a static, or quasi-static, set of guidance >>> for the MN (e.g use access network X for application type A,...) >>> while a rule update requires to be more dynamic. I mean: eventually a >>> policy could be updated depending on network condition (e.g if X >>> overloaded, use access network Y for application type A,...) but a >>> rule reacts on local triggers (e.g. modification of the radio link >>> quality) with a shorter period of variation. So, IMHO, there is no >>> requirement for updating policy on a short period and out-of-band >>> mechanism can be used (e.g. IEEE 802.21 in push mode,...). >> >> Fully agree! >> This is why I do not support the exchange of rules from the HA to the MN= . >> Policies may be exchanged from the HA to the MN, but MIP is definitely >> not the protocol to transport them. >> >> Nicolas >> >>> >>> >>> My 2 cents... >>> >>>> >>>> Is there any reason to restrict where such convertion takes place? >>>> True >>>> that a HA does not know what is going on in the access network, on >>>> the other hand HA may know what is the network condition between HA >>>> and correspondent node. Either of this information is important, if >>>> not equally important. >>>> It is not really difficult to let an MN to reject rules sent by HA, >>>> which in my view would be quite natural. This implies that HA must >>>> follow the rules installed by MN until explicit acceptance has been >>>> received from MN. >>>> Such procedure is very similar to an MN beahviour when initiating >>>> new BU, where MN is not supposed to send any traffic before BU >>>> confirmation. >>>> BTW, what is the numerical representation of "rough consensus"? I >>>> assume is when majority is for, is it so? >>>> Yuri >>>> >>>> >>>> -----Original Message----- >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf >>>> Of Hesham Soliman >>>> Sent: Thursday, May 28, 2009 12:07 PM >>>> To: mext >>>> Subject: [MEXT] Important considerations for directionality of flow >>>> bindings >>>> >>>> Hi all, >>>> >>>> I've always been a fan of the IETF's tradition of rough concensus >>>> (as opposed to voting). To me, this implies that you need to get >>>> your point across and get other people to see that point of view. As >>>> opposed to other organisations that require their members to vote >>>> and end up with rigid political positions. >>>> >>>> The chairs asked us about the directionality question of the flows >>>> bindings. >>>> On the charter question, I said that the charter doesn't need to >>>> mention how a solution should work, but rather what problem needs to >>>> be solved. >>>> Hence, as far as the charter is concerned, I'm fine with >>>> transferring rules "between" the MN and HA without mentioning directio= ns. >>>> >>>> Nevertheless, we still need to agree on identifying the requirement >>>> for the solution. And when it comes to this, I'm strongly against >>>> voting and I'll practice this by explaining in this email why I >>>> think rules can not be transferred from the HA to the MN and that >>>> the only direction that makes sense in MIP is MN->HA. I'll >>>> deliberately ignore arguments like "some people want this" or "an >>>> SDO wants this". They fall under the "meaningless words" >>>> category and I'm incapable of discussing them because they come with >>>> voting attitudes. They all need to be justified if the WG wants to >>>> have a technical _discussion_. >>>> >>>> Here are my reasons: >>>> >>>> 1. The HA does not know whether a CoA is tied to a certain access >>>> technology. It is one thing for the HA to send a message saying >>>> "forward port 80 traffic on a wifi link" (a policy) and a completely >>>> different thing to say "forward port 80 traffic using CoA 3ffe::1" >>>> (a rule). >>>> >>>> 2. You might argue that the HA can be told by the MN that 3ffe::1 is >>>> tied to a wifi access, so what's the problem now? The problem is >>>> that the HA has no idea about dynamic changes on that wifi link. It >>>> doesn't know if it's congested, it doesn't know what application is >>>> using port 80 (it doesn't have to be web traffic) or port 8000 for >>>> that matter and doesn't even know if the AP of that wifi link works >>>> at all. >>>> Finally, it >>>> doesn't know the user's policies or other admin policies for that MN. >>>> This type of information needs to be sent regularly because it >>>> changes all the time and requires serious cross layer integration >>>> including sometimes layer 8 integration! It's completely impractical. >>>> >>>> 3. If the HA installed rules in the MN, what happens if the MN wants >>>> to change those rules. Say the wifi link went down, or the MN's wifi >>>> interface went down and it wants to move that traffic to another >>>> interface. Would the HA reject such move? Does the MN have to >>>> justify to the HA why it needs to move traffic? Does that involve >>>> writing a letter perhaps? >>>> If you say "well in that case, the HA should let the MN move the >>>> traffic" >>>> then I'll ask you: what's the point of having the HA install this >>>> stuff if it has no authority and how does it know the reason for the >>>> MN's movement of the flow? >>>> The way to control how users do things is to incentivise them with >>>> charging models and show them that things work better on certain >>>> technologies, not by installing rules that can't be followed. It's a >>>> broken mindset and we've known that it's broken for a long time. >>>> >>>> 4. Some people mentioned that the HA should be able to revoke flows >>>> on the MN. I'm perfectly fine with that, just extend the binding >>>> revocation draft to handle flows and the rest is pretty straight >>>> forward. >>>> >>>> Finally, I'll indulge in a true story that happened to me a few >>>> years ago when I found that my wifi link wasn't working in a hotel >>>> (no >>>> radio) >>>> and called the help desk. He insisted that the link was up an I >>>> insisted that it wasn't. When I asked him to tell me how he knows >>>> the link is up he said: I can ping the AP! Of course after another 5 >>>> minutes of trying to convince him that pinging the AP doesn't mean >>>> the radio is actually working he sent someone to the hotel who in >>>> turn realised that the radio was not working. >>>> For those people who want rules to be transferred from the HA to the >>>> MN, please think of your HA as this help desk person, i.e. it has no >>>> clue about what's happening at the other end. >>>> >>>> I hope this helps with the realisation that decisions can't be made >>>> here based on voting and that there is little merit to transferring >>>> rules from the HA to the MN. Policies can be transferred without any >>>> problems, but not rules. >>>> >>>> Hesham >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From yuri.ismailov@ericsson.com Wed Jun 3 00:24:45 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C9233A68E1 for ; Wed, 3 Jun 2009 00:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.749 X-Spam-Level: X-Spam-Status: No, score=-7.749 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 sPi5TrgzTAZE for ; Wed, 3 Jun 2009 00:24:13 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CF9833A6AB1 for ; Wed, 3 Jun 2009 00:24:12 -0700 (PDT) X-AuditID: c1b4fb3e-b7b4bae00000395e-43-4a26251cd827 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 9A.D8.14686.C15262A4; Wed, 3 Jun 2009 09:24:13 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jun 2009 09:23:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 09:23:39 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMA= References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 03 Jun 2009 07:23:40.0577 (UTC) FILETIME=[37F4B110:01C9E41C] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 07:24:45 -0000 Hesham, In my view these are events not scenarious. These events are known by HA = but not MN. If HA acts upon events, given that it knows somewhat more = about MN, not only IP addresses, it (HA) can generate new rules and send = them as hint to MN. Back again, MN has four options: - reject, - re-evaluate and reject - re-evaluate and accept - accept The benefit will be obviously that the new rules (if accepted) may llead = to a better overall communication characteristics. /yuri -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Wednesday, June 03, 2009 9:13 AM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings Yuri,=20 Thanks for progressing the discussion. Comments inline >=20 > - network condition towards CN(s) > - the sum of number of hops between MN -> HA and HA -> CN > - Access provider (any access, not necessarily wireless) who offeres=20 > HA services preferences change > - Change of the access provider traffic to another backbone provider=20 > due to the time of the day. > - Traffic condition on HA interface, which accepts traffic from MN if=20 > MN sends on some particular local interface =3D> I'm trying to understand what you mean above. These are all = scenarios, the question is: What is the benefit for the HA to transfer = rules? The HA will not know the path between the MN and CN more than = either node does. So I don't understand what _benefits_ you see here. Hesham >=20 > Pretty much sure that there are more examples and I encourage to think = > about those not from MN point of view but rather from the HA service = provider. >=20 > /yuri >=20 >=20 >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Wednesday, June 03, 2009 8:41 AM > To: Yuri Ismailov; Nicolas Montavont;=20 > pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of=20 > flowbindings >=20 > Yuri, >=20 > It is just rules TRANSFER which is the matter of MIP. So where >> is the logic when saying that MN to HA rules transfer is a practical=20 >> engineering and HA to MN is an academic interest? >=20 > =3D> I think we've (I'm including myself) highlighted several reasons=20 > for why it makes little sense to transfer rules from HA to MN. Instead = > of rat-holing on theory Vs practice, you (or others advocating the=20 > other direction) need to come up with reasons for doing things this=20 > way. This way we can think like engineers about tradeoffs. > Absent that, I don't see any point in having theory Vs practice high=20 > level discussions, which will lead nowhere. >=20 > Hesham >=20 >=20 >>=20 >> Regards >> Yuri >>=20 >> -----Original Message----- >> From: Nicolas Montavont [mailto:ietf@montavont.net] >> Sent: Tuesday, June 02, 2009 5:47 PM >> To: pierrick.seite@orange-ftgroup.com >> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of=20 >> flowbindings >>=20 >> Hi Pierrick, >>=20 >> On Jun 2, 2009, at 4:11 PM, = wrote: >>=20 >>>=20 >>> Hi all, >>>=20 >>> Please see inline comment. >>>=20 >>> Regards, >>> Pierrick >>>=20 >>>> ________________________________________ >>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la=20 >>>> part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 :=20 >>>> Hesham Soliman; mext Objet : Re: [MEXT] Important considerations=20 >>>> for directionality of flowbindings >>>>=20 >>>> Hesham, >>>> This is nice story and makes some sense for the discssion, however=20 >>>> some details are ommited. In your adventure with the helpdesk, it=20 >>>> (the >>>> helpdesk) is a third party service and thus your conclusions make=20 >>>> sence. >>>> Think of the situation when superior of a heldesk person will tell=20 >>>> him/her to check access point in some room. Would it be the same=20 >>>> reaction? I assume not. By that I mean that if, for example, I'll=20 >>>> install home agent in my home network, I can make it know anything=20 >>>> I want about MN, and more intresting is that how I will do it, does = >>>> not require any standardization. >>>> In other words, I'm superior of my HA. >>>> This situation is not unthinkable, I personally believe that this=20 >>>> is much more efficient way of using HA fnctionality as opposed to=20 >>>> big service providers who will have to fight with scalability and=20 >>>> performance. >>>> However, one does not exclude another. >>>> Difference between policies and rules is a convertion step. >>>>=20 >>>>=20 >>>=20 >>>=20 >>> The difference between policy and rules is not only a matter of=20 >>> conversion. A policy, is a static, or quasi-static, set of guidance=20 >>> for the MN (e.g use access network X for application type A,...)=20 >>> while a rule update requires to be more dynamic. I mean: eventually=20 >>> a policy could be updated depending on network condition (e.g if X=20 >>> overloaded, use access network Y for application type A,...) but a=20 >>> rule reacts on local triggers (e.g. modification of the radio link >>> quality) with a shorter period of variation. So, IMHO, there is no=20 >>> requirement for updating policy on a short period and out-of-band=20 >>> mechanism can be used (e.g. IEEE 802.21 in push mode,...). >>=20 >> Fully agree! >> This is why I do not support the exchange of rules from the HA to the = MN. >> Policies may be exchanged from the HA to the MN, but MIP is=20 >> definitely not the protocol to transport them. >>=20 >> Nicolas >>=20 >>>=20 >>>=20 >>> My 2 cents... >>>=20 >>>>=20 >>>> Is there any reason to restrict where such convertion takes place? >>>> True >>>> that a HA does not know what is going on in the access network, on=20 >>>> the other hand HA may know what is the network condition between HA = >>>> and correspondent node. Either of this information is important, if = >>>> not equally important. >>>> It is not really difficult to let an MN to reject rules sent by HA, = >>>> which in my view would be quite natural. This implies that HA must=20 >>>> follow the rules installed by MN until explicit acceptance has been = >>>> received from MN. >>>> Such procedure is very similar to an MN beahviour when initiating=20 >>>> new BU, where MN is not supposed to send any traffic before BU=20 >>>> confirmation. >>>> BTW, what is the numerical representation of "rough consensus"? I=20 >>>> assume is when majority is for, is it so? >>>> Yuri >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 >>>> Behalf Of Hesham Soliman >>>> Sent: Thursday, May 28, 2009 12:07 PM >>>> To: mext >>>> Subject: [MEXT] Important considerations for directionality of flow = >>>> bindings >>>>=20 >>>> Hi all, >>>>=20 >>>> I've always been a fan of the IETF's tradition of rough concensus=20 >>>> (as opposed to voting). To me, this implies that you need to get=20 >>>> your point across and get other people to see that point of view.=20 >>>> As opposed to other organisations that require their members to=20 >>>> vote and end up with rigid political positions. >>>>=20 >>>> The chairs asked us about the directionality question of the flows=20 >>>> bindings. >>>> On the charter question, I said that the charter doesn't need to=20 >>>> mention how a solution should work, but rather what problem needs=20 >>>> to be solved. >>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>> transferring rules "between" the MN and HA without mentioning = directions. >>>>=20 >>>> Nevertheless, we still need to agree on identifying the requirement = >>>> for the solution. And when it comes to this, I'm strongly against=20 >>>> voting and I'll practice this by explaining in this email why I=20 >>>> think rules can not be transferred from the HA to the MN and that=20 >>>> the only direction that makes sense in MIP is MN->HA. I'll=20 >>>> deliberately ignore arguments like "some people want this" or "an=20 >>>> SDO wants this". They fall under the "meaningless words" >>>> category and I'm incapable of discussing them because they come=20 >>>> with voting attitudes. They all need to be justified if the WG=20 >>>> wants to have a technical _discussion_. >>>>=20 >>>> Here are my reasons: >>>>=20 >>>> 1. The HA does not know whether a CoA is tied to a certain access=20 >>>> technology. It is one thing for the HA to send a message saying=20 >>>> "forward port 80 traffic on a wifi link" (a policy) and a=20 >>>> completely different thing to say "forward port 80 traffic using = CoA 3ffe::1" >>>> (a rule). >>>>=20 >>>> 2. You might argue that the HA can be told by the MN that 3ffe::1=20 >>>> is tied to a wifi access, so what's the problem now? The problem is = >>>> that the HA has no idea about dynamic changes on that wifi link. It = >>>> doesn't know if it's congested, it doesn't know what application is = >>>> using port 80 (it doesn't have to be web traffic) or port 8000 for=20 >>>> that matter and doesn't even know if the AP of that wifi link works = >>>> at all. >>>> Finally, it >>>> doesn't know the user's policies or other admin policies for that = MN. >>>> This type of information needs to be sent regularly because it=20 >>>> changes all the time and requires serious cross layer integration=20 >>>> including sometimes layer 8 integration! It's completely = impractical. >>>>=20 >>>> 3. If the HA installed rules in the MN, what happens if the MN=20 >>>> wants to change those rules. Say the wifi link went down, or the=20 >>>> MN's wifi interface went down and it wants to move that traffic to=20 >>>> another interface. Would the HA reject such move? Does the MN have=20 >>>> to justify to the HA why it needs to move traffic? Does that=20 >>>> involve writing a letter perhaps? >>>> If you say "well in that case, the HA should let the MN move the=20 >>>> traffic" >>>> then I'll ask you: what's the point of having the HA install this=20 >>>> stuff if it has no authority and how does it know the reason for=20 >>>> the MN's movement of the flow? >>>> The way to control how users do things is to incentivise them with=20 >>>> charging models and show them that things work better on certain=20 >>>> technologies, not by installing rules that can't be followed. It's=20 >>>> a broken mindset and we've known that it's broken for a long time. >>>>=20 >>>> 4. Some people mentioned that the HA should be able to revoke flows = >>>> on the MN. I'm perfectly fine with that, just extend the binding=20 >>>> revocation draft to handle flows and the rest is pretty straight=20 >>>> forward. >>>>=20 >>>> Finally, I'll indulge in a true story that happened to me a few=20 >>>> years ago when I found that my wifi link wasn't working in a hotel=20 >>>> (no >>>> radio) >>>> and called the help desk. He insisted that the link was up an I=20 >>>> insisted that it wasn't. When I asked him to tell me how he knows=20 >>>> the link is up he said: I can ping the AP! Of course after another=20 >>>> 5 minutes of trying to convince him that pinging the AP doesn't=20 >>>> mean the radio is actually working he sent someone to the hotel who = >>>> in turn realised that the radio was not working. >>>> For those people who want rules to be transferred from the HA to=20 >>>> the MN, please think of your HA as this help desk person, i.e. it=20 >>>> has no clue about what's happening at the other end. >>>>=20 >>>> I hope this helps with the realisation that decisions can't be made = >>>> here based on voting and that there is little merit to transferring = >>>> rules from the HA to the MN. Policies can be transferred without=20 >>>> any problems, but not rules. >>>>=20 >>>> Hesham >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>=20 >=20 >=20 From yuri.ismailov@ericsson.com Wed Jun 3 00:35:54 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79C1F3A68E1 for ; Wed, 3 Jun 2009 00:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.849 X-Spam-Level: X-Spam-Status: No, score=-7.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 hGIa8-uzqnqe for ; Wed, 3 Jun 2009 00:35:53 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 214483A677C for ; Wed, 3 Jun 2009 00:35:51 -0700 (PDT) X-AuditID: c1b4fb3e-b7b4bae00000395e-28-4a2627d74fbf Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 41.6A.14686.7D7262A4; Wed, 3 Jun 2009 09:35:51 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jun 2009 09:34:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 09:34:26 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnkHMO2PRhD8KADTQqq1XDdVva7lgAAEq1A References: From: "Yuri Ismailov" To: "George Tsirtsis" X-OriginalArrivalTime: 03 Jun 2009 07:34:26.0862 (UTC) FILETIME=[B92BF4E0:01C9E41D] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 07:35:54 -0000 George, I do not think that my employment matters for this discussion. I suggest we focus then on corporate scenarious or residential networks, = which would have similar access provider functions which I described = eralier /yuri=20 -----Original Message----- From: George Tsirtsis [mailto:tsirtsis@googlemail.com]=20 Sent: Wednesday, June 03, 2009 9:18 AM To: Yuri Ismailov Cc: Hesham Soliman; Nicolas Montavont; = pierrick.seite@orange-ftgroup.com; mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings Yuri, Since you are working for a vendor to cellular operators it should be = trivial for you to check what the bottlenecks in cellular and other = wireless networks are. In cellular, by far the biggest bottleneck is the wireless link i.e., = the airlink between the mobile and the base station (BS) / access point = (AP). The next bottleneck is the backhaul link connecting the BS/AP to the = aggregation router/switch depending on RAN architecture. These two links are simply too expensive to overdimention; the former = due to spectrum cost/constraints, and the latter due to the high = cost/volume of last-mile wires required to go to all the BS/AP. In all networks, technologies, and deployments I have been involved = with, the rest of the network is considered pretty much to be = overdimentioned. This is why all the conditions to which you claim the = HA may have better view of (even if one considers the HA to somehow know = the condition of the whole network, which of course is nonsense), are in = any case not relevant in practice. And they are certainly not relevant = to the uplink traffic sent by the mobile over the first 2 links, which = are also the only relevant bottlenecks in the system. George On Wed, Jun 3, 2009 at 8:00 AM, Yuri Ismailov = wrote: > Hesham, > "Academic interest" is not my argument and I agree that this kind of = discussion will take us nowhere. You withdrew this statement from the = context. > Some examples: > > - network condition towards CN(s) > - the sum of number of hops between MN -> HA and HA -> CN > - Access provider (any access, not necessarily wireless) who offeres=20 > HA services preferences change > - Change of the access provider traffic to another backbone provider = due to the time of the day. > - Traffic condition on HA interface, which accepts traffic from MN if=20 > MN sends on some particular local interface > > Pretty much sure that there are more examples and I encourage to think = about those not from MN point of view but rather from the HA service = provider. > > /yuri > > > > > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Wednesday, June 03, 2009 8:41 AM > To: Yuri Ismailov; Nicolas Montavont;=20 > pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of=20 > flowbindings > > Yuri, > > =A0It is just rules TRANSFER which is the matter of MIP. So where >> is the logic when saying that MN to HA rules transfer is a practical=20 >> engineering and HA to MN is an academic interest? > > =3D> I think we've (I'm including myself) highlighted several reasons = for why it makes little sense to transfer rules from HA to MN. Instead = of rat-holing on theory Vs practice, you (or others advocating the other = direction) need to come up with reasons for doing things this way. This = way we can think like engineers about tradeoffs. > Absent that, I don't see any point in having theory Vs practice high = level discussions, which will lead nowhere. > > Hesham > > >> >> Regards >> Yuri >> >> -----Original Message----- >> From: Nicolas Montavont [mailto:ietf@montavont.net] >> Sent: Tuesday, June 02, 2009 5:47 PM >> To: pierrick.seite@orange-ftgroup.com >> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of=20 >> flowbindings >> >> Hi Pierrick, >> >> On Jun 2, 2009, at 4:11 PM, = wrote: >> >>> >>> Hi all, >>> >>> Please see inline comment. >>> >>> Regards, >>> Pierrick >>> >>>> ________________________________________ >>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la=20 >>>> part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 :=20 >>>> Hesham Soliman; mext Objet : Re: [MEXT] Important considerations=20 >>>> for directionality of flowbindings >>>> >>>> Hesham, >>>> This is nice story and makes some sense for the discssion, however=20 >>>> some details are ommited. In your adventure with the helpdesk, it=20 >>>> (the >>>> helpdesk) is a third party service and thus your conclusions make=20 >>>> sence. >>>> Think of the situation when superior of a heldesk person will tell=20 >>>> him/her to check access point in some room. Would it be the same=20 >>>> reaction? I assume not. By that I mean that if, for example, I'll=20 >>>> install home agent in my home network, I can make it know anything=20 >>>> I want about MN, and more intresting is that how I will do it, does = >>>> not require any standardization. >>>> In other words, I'm superior of my HA. >>>> This situation is not unthinkable, I personally believe that this=20 >>>> is much more efficient way of using HA fnctionality as opposed to=20 >>>> big service providers who will have to fight with scalability and=20 >>>> performance. >>>> However, one does not exclude another. >>>> Difference between policies and rules is a convertion step. >>>> >>>> >>> >>> >>> The difference between policy and rules is not only a matter of=20 >>> conversion. A policy, is a static, or quasi-static, set of guidance=20 >>> for the MN (e.g use access network X for application type A,...)=20 >>> while a rule update requires to be more dynamic. I mean: eventually=20 >>> a policy could be updated depending on network condition (e.g if X=20 >>> overloaded, use access network Y for application type A,...) but a=20 >>> rule reacts on local triggers (e.g. modification of the radio link >>> quality) with a shorter period of variation. So, IMHO, there is no=20 >>> requirement for updating policy on a short period and out-of-band=20 >>> mechanism can be used (e.g. IEEE 802.21 in push mode,...). >> >> Fully agree! >> This is why I do not support the exchange of rules from the HA to the = MN. >> Policies may be exchanged from the HA to the MN, but MIP is=20 >> definitely not the protocol to transport them. >> >> Nicolas >> >>> >>> >>> My 2 cents... >>> >>>> >>>> Is there any reason to restrict where such convertion takes place? >>>> True >>>> that a HA does not know what is going on in the access network, on=20 >>>> the other hand HA may know what is the network condition between HA = >>>> and correspondent node. Either of this information is important, if = >>>> not equally important. >>>> It is not really difficult to let an MN to reject rules sent by HA, = >>>> which in my view would be quite natural. This implies that HA must=20 >>>> follow the rules installed by MN until explicit acceptance has been = >>>> received from MN. >>>> Such procedure is very similar to an MN beahviour when initiating=20 >>>> new BU, where MN is not supposed to send any traffic before BU=20 >>>> confirmation. >>>> BTW, what is the numerical representation of "rough consensus"? I=20 >>>> assume is when majority is for, is it so? >>>> Yuri >>>> >>>> >>>> -----Original Message----- >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 >>>> Behalf Of Hesham Soliman >>>> Sent: Thursday, May 28, 2009 12:07 PM >>>> To: mext >>>> Subject: [MEXT] Important considerations for directionality of flow = >>>> bindings >>>> >>>> Hi all, >>>> >>>> I've always been a fan of the IETF's tradition of rough concensus=20 >>>> (as opposed to voting). To me, this implies that you need to get=20 >>>> your point across and get other people to see that point of view.=20 >>>> As opposed to other organisations that require their members to=20 >>>> vote and end up with rigid political positions. >>>> >>>> The chairs asked us about the directionality question of the flows=20 >>>> bindings. >>>> On the charter question, I said that the charter doesn't need to=20 >>>> mention how a solution should work, but rather what problem needs=20 >>>> to be solved. >>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>> transferring rules "between" the MN and HA without mentioning = directions. >>>> >>>> Nevertheless, we still need to agree on identifying the requirement = >>>> for the solution. And when it comes to this, I'm strongly against=20 >>>> voting and I'll practice this by explaining in this email why I=20 >>>> think rules can not be transferred from the HA to the MN and that=20 >>>> the only direction that makes sense in MIP is MN->HA. I'll=20 >>>> deliberately ignore arguments like "some people want this" or "an=20 >>>> SDO wants this". They fall under the "meaningless words" >>>> category and I'm incapable of discussing them because they come=20 >>>> with voting attitudes. They all need to be justified if the WG=20 >>>> wants to have a technical _discussion_. >>>> >>>> Here are my reasons: >>>> >>>> 1. The HA does not know whether a CoA is tied to a certain access=20 >>>> technology. It is one thing for the HA to send a message saying=20 >>>> "forward port 80 traffic on a wifi link" (a policy) and a=20 >>>> completely different thing to say "forward port 80 traffic using = CoA 3ffe::1" >>>> (a rule). >>>> >>>> 2. You might argue that the HA can be told by the MN that 3ffe::1=20 >>>> is tied to a wifi access, so what's the problem now? The problem is = >>>> that the HA has no idea about dynamic changes on that wifi link. It = >>>> doesn't know if it's congested, it doesn't know what application is = >>>> using port 80 (it doesn't have to be web traffic) or port 8000 for=20 >>>> that matter and doesn't even know if the AP of that wifi link works = >>>> at all. >>>> Finally, it >>>> doesn't know the user's policies or other admin policies for that = MN. >>>> This type of information needs to be sent regularly because it=20 >>>> changes all the time and requires serious cross layer integration=20 >>>> including sometimes layer 8 integration! It's completely = impractical. >>>> >>>> 3. If the HA installed rules in the MN, what happens if the MN=20 >>>> wants to change those rules. Say the wifi link went down, or the=20 >>>> MN's wifi interface went down and it wants to move that traffic to=20 >>>> another interface. Would the HA reject such move? Does the MN have=20 >>>> to justify to the HA why it needs to move traffic? Does that=20 >>>> involve writing a letter perhaps? >>>> If you say "well in that case, the HA should let the MN move the=20 >>>> traffic" >>>> then I'll ask you: what's the point of having the HA install this=20 >>>> stuff if it has no authority and how does it know the reason for=20 >>>> the MN's movement of the flow? >>>> The way to control how users do things is to incentivise them with=20 >>>> charging models and show them that things work better on certain=20 >>>> technologies, not by installing rules that can't be followed. It's=20 >>>> a broken mindset and we've known that it's broken for a long time. >>>> >>>> 4. Some people mentioned that the HA should be able to revoke flows = >>>> on the MN. I'm perfectly fine with that, just extend the binding=20 >>>> revocation draft to handle flows and the rest is pretty straight=20 >>>> forward. >>>> >>>> Finally, I'll indulge in a true story that happened to me a few=20 >>>> years ago when I found that my wifi link wasn't working in a hotel=20 >>>> (no >>>> radio) >>>> and called the help desk. He insisted that the link was up an I=20 >>>> insisted that it wasn't. When I asked him to tell me how he knows=20 >>>> the link is up he said: I can ping the AP! Of course after another=20 >>>> 5 minutes of trying to convince him that pinging the AP doesn't=20 >>>> mean the radio is actually working he sent someone to the hotel who = >>>> in turn realised that the radio was not working. >>>> For those people who want rules to be transferred from the HA to=20 >>>> the MN, please think of your HA as this help desk person, i.e. it=20 >>>> has no clue about what's happening at the other end. >>>> >>>> I hope this helps with the realisation that decisions can't be made = >>>> here based on voting and that there is little merit to transferring = >>>> rules from the HA to the MN. Policies can be transferred without=20 >>>> any problems, but not rules. >>>> >>>> Hesham >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From hesham@elevatemobile.com Wed Jun 3 01:10:39 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02CB83A6A18 for ; Wed, 3 Jun 2009 01:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 wl-T7muRjeo2 for ; Wed, 3 Jun 2009 01:10:37 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id D40BB28C162 for ; Wed, 3 Jun 2009 01:10:36 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MBlYF-0007iz-AB; Wed, 03 Jun 2009 18:10:24 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Wed, 03 Jun 2009 18:10:13 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 08:10:39 -0000 Yuri, I can't parse those events you refer to. I'l answer both emails here. First the events you refer to: >> - network condition towards CN(s) >> - the sum of number of hops between MN -> HA and HA -> CN =3D> What's the event? A change in those conditions? The MN knows the conditions of the e2e path as well as or better than the HA. What is the benefit of having the HA send a hint and how reliable is that hint anyway? >> - Access provider (any access, not necessarily wireless) who offeres >> HA services preferences change =3D> Preferences change to what?? How does it know if such change works for the MN at all? This is way too vague to be able to discuss tradeoffs. >> - Change of the access provider traffic to another backbone provider >> due to the time of the day. >> - Traffic condition on HA interface, which accepts traffic from MN if >> MN sends on some particular local interface =3D> These are path changes. The HA has _no idea_ how such a change affects each MN/CN combination and it's "hint" can cause more problems than it solves. BTW, if you're talking about hints then we're no longer talking about installing bindings in the MN. This is a different topic. MIP doesn't transfer hints, it pretty much sends "orders" from one end to another. Now to the actions required by the MN: > - reject, > - re-evaluate and reject > - re-evaluate and accept > - accept =3D> First, by assuming that the MN can reject the "hint" as you call it you invalidate the whole argument for the HA to install rules. Rejecting a hint or even evaluating it means that the MN knows more. Therefore, the HA's hin= t is a complete waste of bandwidth. I'm still confused about the _benefits_ you see here. Or are you assuming that the MN can't know those hints without the HA's involvement? But if you're assuming that, then how can it reject the hints? This whole proposal makes no sense to me at all. Not to mention the complexity you implicitly assume in order to generate those, hopefully reliable, hints. Hesham On 3/06/09 5:23 PM, "Yuri Ismailov" wrote: > Hesham, >=20 > In my view these are events not scenarious. These events are known by HA = but > not MN. If HA acts upon events, given that it knows somewhat more about M= N, > not only IP addresses, it (HA) can generate new rules and send them as hi= nt to > MN. Back again, MN has four options: >=20 > The benefit will be obviously that the new rules (if accepted) may llead = to a > better overall communication characteristics. >=20 > /yuri >=20 >=20 > =3D> I'm trying to understand what you mean above. These are all scenarios,= the > question is: What is the benefit for the HA to transfer rules? The HA wil= l not > know the path between the MN and CN more than either node does. So I don'= t > understand what _benefits_ you see here. >=20 > Hesham >=20 >>=20 >> Pretty much sure that there are more examples and I encourage to think >> about those not from MN point of view but rather from the HA service >> provider. >>=20 >> /yuri >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Wednesday, June 03, 2009 8:41 AM >> To: Yuri Ismailov; Nicolas Montavont; >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of >> flowbindings >>=20 >> Yuri, >>=20 >> It is just rules TRANSFER which is the matter of MIP. So where >>> is the logic when saying that MN to HA rules transfer is a practical >>> engineering and HA to MN is an academic interest? >>=20 >> =3D> I think we've (I'm including myself) highlighted several reasons >> for why it makes little sense to transfer rules from HA to MN. Instead >> of rat-holing on theory Vs practice, you (or others advocating the >> other direction) need to come up with reasons for doing things this >> way. This way we can think like engineers about tradeoffs. >> Absent that, I don't see any point in having theory Vs practice high >> level discussions, which will lead nowhere. >>=20 >> Hesham >>=20 >>=20 >>>=20 >>> Regards >>> Yuri >>>=20 >>> -----Original Message----- >>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>> Sent: Tuesday, June 02, 2009 5:47 PM >>> To: pierrick.seite@orange-ftgroup.com >>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of >>> flowbindings >>>=20 >>> Hi Pierrick, >>>=20 >>> On Jun 2, 2009, at 4:11 PM, wrote: >>>=20 >>>>=20 >>>> Hi all, >>>>=20 >>>> Please see inline comment. >>>>=20 >>>> Regards, >>>> Pierrick >>>>=20 >>>>> ________________________________________ >>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la >>>>> part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 : >>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important considerations >>>>> for directionality of flowbindings >>>>>=20 >>>>> Hesham, >>>>> This is nice story and makes some sense for the discssion, however >>>>> some details are ommited. In your adventure with the helpdesk, it >>>>> (the >>>>> helpdesk) is a third party service and thus your conclusions make >>>>> sence. >>>>> Think of the situation when superior of a heldesk person will tell >>>>> him/her to check access point in some room. Would it be the same >>>>> reaction? I assume not. By that I mean that if, for example, I'll >>>>> install home agent in my home network, I can make it know anything >>>>> I want about MN, and more intresting is that how I will do it, does >>>>> not require any standardization. >>>>> In other words, I'm superior of my HA. >>>>> This situation is not unthinkable, I personally believe that this >>>>> is much more efficient way of using HA fnctionality as opposed to >>>>> big service providers who will have to fight with scalability and >>>>> performance. >>>>> However, one does not exclude another. >>>>> Difference between policies and rules is a convertion step. >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> The difference between policy and rules is not only a matter of >>>> conversion. A policy, is a static, or quasi-static, set of guidance >>>> for the MN (e.g use access network X for application type A,...) >>>> while a rule update requires to be more dynamic. I mean: eventually >>>> a policy could be updated depending on network condition (e.g if X >>>> overloaded, use access network Y for application type A,...) but a >>>> rule reacts on local triggers (e.g. modification of the radio link >>>> quality) with a shorter period of variation. So, IMHO, there is no >>>> requirement for updating policy on a short period and out-of-band >>>> mechanism can be used (e.g. IEEE 802.21 in push mode,...). >>>=20 >>> Fully agree! >>> This is why I do not support the exchange of rules from the HA to the M= N. >>> Policies may be exchanged from the HA to the MN, but MIP is >>> definitely not the protocol to transport them. >>>=20 >>> Nicolas >>>=20 >>>>=20 >>>>=20 >>>> My 2 cents... >>>>=20 >>>>>=20 >>>>> Is there any reason to restrict where such convertion takes place? >>>>> True >>>>> that a HA does not know what is going on in the access network, on >>>>> the other hand HA may know what is the network condition between HA >>>>> and correspondent node. Either of this information is important, if >>>>> not equally important. >>>>> It is not really difficult to let an MN to reject rules sent by HA, >>>>> which in my view would be quite natural. This implies that HA must >>>>> follow the rules installed by MN until explicit acceptance has been >>>>> received from MN. >>>>> Such procedure is very similar to an MN beahviour when initiating >>>>> new BU, where MN is not supposed to send any traffic before BU >>>>> confirmation. >>>>> BTW, what is the numerical representation of "rough consensus"? I >>>>> assume is when majority is for, is it so? >>>>> Yuri >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>>> Behalf Of Hesham Soliman >>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>> To: mext >>>>> Subject: [MEXT] Important considerations for directionality of flow >>>>> bindings >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> I've always been a fan of the IETF's tradition of rough concensus >>>>> (as opposed to voting). To me, this implies that you need to get >>>>> your point across and get other people to see that point of view. >>>>> As opposed to other organisations that require their members to >>>>> vote and end up with rigid political positions. >>>>>=20 >>>>> The chairs asked us about the directionality question of the flows >>>>> bindings. >>>>> On the charter question, I said that the charter doesn't need to >>>>> mention how a solution should work, but rather what problem needs >>>>> to be solved. >>>>> Hence, as far as the charter is concerned, I'm fine with >>>>> transferring rules "between" the MN and HA without mentioning directi= ons. >>>>>=20 >>>>> Nevertheless, we still need to agree on identifying the requirement >>>>> for the solution. And when it comes to this, I'm strongly against >>>>> voting and I'll practice this by explaining in this email why I >>>>> think rules can not be transferred from the HA to the MN and that >>>>> the only direction that makes sense in MIP is MN->HA. I'll >>>>> deliberately ignore arguments like "some people want this" or "an >>>>> SDO wants this". They fall under the "meaningless words" >>>>> category and I'm incapable of discussing them because they come >>>>> with voting attitudes. They all need to be justified if the WG >>>>> wants to have a technical _discussion_. >>>>>=20 >>>>> Here are my reasons: >>>>>=20 >>>>> 1. The HA does not know whether a CoA is tied to a certain access >>>>> technology. It is one thing for the HA to send a message saying >>>>> "forward port 80 traffic on a wifi link" (a policy) and a >>>>> completely different thing to say "forward port 80 traffic using CoA >>>>> 3ffe::1" >>>>> (a rule). >>>>>=20 >>>>> 2. You might argue that the HA can be told by the MN that 3ffe::1 >>>>> is tied to a wifi access, so what's the problem now? The problem is >>>>> that the HA has no idea about dynamic changes on that wifi link. It >>>>> doesn't know if it's congested, it doesn't know what application is >>>>> using port 80 (it doesn't have to be web traffic) or port 8000 for >>>>> that matter and doesn't even know if the AP of that wifi link works >>>>> at all. >>>>> Finally, it >>>>> doesn't know the user's policies or other admin policies for that MN. >>>>> This type of information needs to be sent regularly because it >>>>> changes all the time and requires serious cross layer integration >>>>> including sometimes layer 8 integration! It's completely impractical. >>>>>=20 >>>>> 3. If the HA installed rules in the MN, what happens if the MN >>>>> wants to change those rules. Say the wifi link went down, or the >>>>> MN's wifi interface went down and it wants to move that traffic to >>>>> another interface. Would the HA reject such move? Does the MN have >>>>> to justify to the HA why it needs to move traffic? Does that >>>>> involve writing a letter perhaps? >>>>> If you say "well in that case, the HA should let the MN move the >>>>> traffic" >>>>> then I'll ask you: what's the point of having the HA install this >>>>> stuff if it has no authority and how does it know the reason for >>>>> the MN's movement of the flow? >>>>> The way to control how users do things is to incentivise them with >>>>> charging models and show them that things work better on certain >>>>> technologies, not by installing rules that can't be followed. It's >>>>> a broken mindset and we've known that it's broken for a long time. >>>>>=20 >>>>> 4. Some people mentioned that the HA should be able to revoke flows >>>>> on the MN. I'm perfectly fine with that, just extend the binding >>>>> revocation draft to handle flows and the rest is pretty straight >>>>> forward. >>>>>=20 >>>>> Finally, I'll indulge in a true story that happened to me a few >>>>> years ago when I found that my wifi link wasn't working in a hotel >>>>> (no >>>>> radio) >>>>> and called the help desk. He insisted that the link was up an I >>>>> insisted that it wasn't. When I asked him to tell me how he knows >>>>> the link is up he said: I can ping the AP! Of course after another >>>>> 5 minutes of trying to convince him that pinging the AP doesn't >>>>> mean the radio is actually working he sent someone to the hotel who >>>>> in turn realised that the radio was not working. >>>>> For those people who want rules to be transferred from the HA to >>>>> the MN, please think of your HA as this help desk person, i.e. it >>>>> has no clue about what's happening at the other end. >>>>>=20 >>>>> I hope this helps with the realisation that decisions can't be made >>>>> here based on voting and that there is little merit to transferring >>>>> rules from the HA to the MN. Policies can be transferred without >>>>> any problems, but not rules. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>=20 >>=20 >>=20 >=20 >=20 From tsirtsis@googlemail.com Wed Jun 3 02:17:24 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7423A6ACA for ; Wed, 3 Jun 2009 02:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2] 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 Z0ARcwEhoiZE for ; Wed, 3 Jun 2009 02:17:22 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 5D45C3A6986 for ; Wed, 3 Jun 2009 02:17:22 -0700 (PDT) Received: by mail-bw0-f163.google.com with SMTP id 7so9360bwz.37 for ; Wed, 03 Jun 2009 02:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=04dKy5wvlWLqyKl79+jSQdvaowJExTqC5NECZl29c3M=; b=Ie3JqoswXokU7WcI+GVoLRYPcZJimVJ1SklfTS8zOirH+3rsbXiLbHy75KMvKx4uXP 16dn6puKXvOmhuSNYM49Mx/wpj3H1JennoJddXp3poIgh2zUc/Hy1YL2i3y/lnQUbhyB FaOvF2FF48PFe4RxIkyHg7Ztac3HU7Aeg4wTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hLJSgTZhBvCg9gmwm+1GL1bnx+i7IZ3f8Thmg9a2KtQeGKXAPG79DSbYUW3xNgxX9x 8thryMqOD3Vo6fwNZ14Y+GeJw6Cz4EccfGRullc/S7avLnUazXtQ9e0so8J6/bMqy9Y9 wJVpWhDxPlRYW4C5gASXGmBHGHGZ57zOU55LQ= MIME-Version: 1.0 Received: by 10.239.134.65 with SMTP id 1mr55819hby.160.1244020643684; Wed, 03 Jun 2009 02:17:23 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jun 2009 10:17:23 +0100 Message-ID: From: George Tsirtsis To: Yuri Ismailov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 09:17:24 -0000 I only referred to your employment regarding access you might have to credible and relevant information. I hope you did not take it the wrong way. Corporate and residential scenarios are even less relevant. An HA at home or at the office can know even less relevant information than an HA in say a cellular system, when the mobile is roaming somewhere on the Internet. But we keep dancing around the same arguments...no much progress. George On Wed, Jun 3, 2009 at 8:34 AM, Yuri Ismailov wrote: > George, > I do not think that my employment matters for this discussion. > I suggest we focus then on corporate scenarious or residential networks, = which would have similar access provider functions which I described eralie= r > /yuri > > -----Original Message----- > From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > Sent: Wednesday, June 03, 2009 9:18 AM > To: Yuri Ismailov > Cc: Hesham Soliman; Nicolas Montavont; pierrick.seite@orange-ftgroup.com;= mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of flowbi= ndings > > Yuri, > > Since you are working for a vendor to cellular operators it should be tri= vial for you to check what the bottlenecks in cellular and other wireless n= etworks are. > > In cellular, by far the biggest bottleneck is the wireless link i.e., the= airlink between the mobile and the base station (BS) / access point (AP). > The next bottleneck is the backhaul link connecting the BS/AP to the aggr= egation router/switch depending on RAN architecture. > > These two links are simply too expensive to overdimention; the former due= to spectrum cost/constraints, and the latter due to the high cost/volume o= f last-mile wires required to go to all the BS/AP. > > In all networks, technologies, and deployments I have been involved with,= the rest of the network is considered pretty much to be overdimentioned. T= his is why all the conditions to which you claim the HA may have better vie= w of (even if one considers the HA to somehow know the condition of the who= le network, which of course is nonsense), are in any case not relevant in p= ractice. And they are certainly not relevant to the uplink traffic sent by = the mobile over the first 2 links, which are also the only relevant bottlen= ecks in the system. > > George > > On Wed, Jun 3, 2009 at 8:00 AM, Yuri Ismailov wrote: >> Hesham, >> "Academic interest" is not my argument and I agree that this kind of dis= cussion will take us nowhere. You withdrew this statement from the context. >> Some examples: >> >> - network condition towards CN(s) >> - the sum of number of hops between MN -> HA and HA -> CN >> - Access provider (any access, not necessarily wireless) who offeres >> HA services preferences change >> - Change of the access provider traffic to another backbone provider due= to the time of the day. >> - Traffic condition on HA interface, which accepts traffic from MN if >> MN sends on some particular local interface >> >> Pretty much sure that there are more examples and I encourage to think a= bout those not from MN point of view but rather from the HA service provide= r. >> >> /yuri >> >> >> >> >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Wednesday, June 03, 2009 8:41 AM >> To: Yuri Ismailov; Nicolas Montavont; >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of >> flowbindings >> >> Yuri, >> >> =C2=A0It is just rules TRANSFER which is the matter of MIP. So where >>> is the logic when saying that MN to HA rules transfer is a practical >>> engineering and HA to MN is an academic interest? >> >> =3D> I think we've (I'm including myself) highlighted several reasons fo= r why it makes little sense to transfer rules from HA to MN. Instead of rat= -holing on theory Vs practice, you (or others advocating the other directio= n) need to come up with reasons for doing things this way. This way we can = think like engineers about tradeoffs. >> Absent that, I don't see any point in having theory Vs practice high lev= el discussions, which will lead nowhere. >> >> Hesham >> >> >>> >>> Regards >>> Yuri >>> >>> -----Original Message----- >>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>> Sent: Tuesday, June 02, 2009 5:47 PM >>> To: pierrick.seite@orange-ftgroup.com >>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of >>> flowbindings >>> >>> Hi Pierrick, >>> >>> On Jun 2, 2009, at 4:11 PM, wrote: >>> >>>> >>>> Hi all, >>>> >>>> Please see inline comment. >>>> >>>> Regards, >>>> Pierrick >>>> >>>>> ________________________________________ >>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la >>>>> part de Yuri Ismailov Envoy=C3=A9 : vendredi 29 mai 2009 09:35 =C3=80= : >>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important considerations >>>>> for directionality of flowbindings >>>>> >>>>> Hesham, >>>>> This is nice story and makes some sense for the discssion, however >>>>> some details are ommited. In your adventure with the helpdesk, it >>>>> (the >>>>> helpdesk) is a third party service and thus your conclusions make >>>>> sence. >>>>> Think of the situation when superior of a heldesk person will tell >>>>> him/her to check access point in some room. Would it be the same >>>>> reaction? I assume not. By that I mean that if, for example, I'll >>>>> install home agent in my home network, I can make it know anything >>>>> I want about MN, and more intresting is that how I will do it, does >>>>> not require any standardization. >>>>> In other words, I'm superior of my HA. >>>>> This situation is not unthinkable, I personally believe that this >>>>> is much more efficient way of using HA fnctionality as opposed to >>>>> big service providers who will have to fight with scalability and >>>>> performance. >>>>> However, one does not exclude another. >>>>> Difference between policies and rules is a convertion step. >>>>> >>>>> >>>> >>>> >>>> The difference between policy and rules is not only a matter of >>>> conversion. A policy, is a static, or quasi-static, set of guidance >>>> for the MN (e.g use access network X for application type A,...) >>>> while a rule update requires to be more dynamic. I mean: eventually >>>> a policy could be updated depending on network condition (e.g if X >>>> overloaded, use access network Y for application type A,...) but a >>>> rule reacts on local triggers (e.g. modification of the radio link >>>> quality) with a shorter period of variation. So, IMHO, there is no >>>> requirement for updating policy on a short period and out-of-band >>>> mechanism can be used (e.g. IEEE 802.21 in push mode,...). >>> >>> Fully agree! >>> This is why I do not support the exchange of rules from the HA to the M= N. >>> Policies may be exchanged from the HA to the MN, but MIP is >>> definitely not the protocol to transport them. >>> >>> Nicolas >>> >>>> >>>> >>>> My 2 cents... >>>> >>>>> >>>>> Is there any reason to restrict where such convertion takes place? >>>>> True >>>>> that a HA does not know what is going on in the access network, on >>>>> the other hand HA may know what is the network condition between HA >>>>> and correspondent node. Either of this information is important, if >>>>> not equally important. >>>>> It is not really difficult to let an MN to reject rules sent by HA, >>>>> which in my view would be quite natural. This implies that HA must >>>>> follow the rules installed by MN until explicit acceptance has been >>>>> received from MN. >>>>> Such procedure is very similar to an MN beahviour when initiating >>>>> new BU, where MN is not supposed to send any traffic before BU >>>>> confirmation. >>>>> BTW, what is the numerical representation of "rough consensus"? I >>>>> assume is when majority is for, is it so? >>>>> Yuri >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>>> Behalf Of Hesham Soliman >>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>> To: mext >>>>> Subject: [MEXT] Important considerations for directionality of flow >>>>> bindings >>>>> >>>>> Hi all, >>>>> >>>>> I've always been a fan of the IETF's tradition of rough concensus >>>>> (as opposed to voting). To me, this implies that you need to get >>>>> your point across and get other people to see that point of view. >>>>> As opposed to other organisations that require their members to >>>>> vote and end up with rigid political positions. >>>>> >>>>> The chairs asked us about the directionality question of the flows >>>>> bindings. >>>>> On the charter question, I said that the charter doesn't need to >>>>> mention how a solution should work, but rather what problem needs >>>>> to be solved. >>>>> Hence, as far as the charter is concerned, I'm fine with >>>>> transferring rules "between" the MN and HA without mentioning directi= ons. >>>>> >>>>> Nevertheless, we still need to agree on identifying the requirement >>>>> for the solution. And when it comes to this, I'm strongly against >>>>> voting and I'll practice this by explaining in this email why I >>>>> think rules can not be transferred from the HA to the MN and that >>>>> the only direction that makes sense in MIP is MN->HA. I'll >>>>> deliberately ignore arguments like "some people want this" or "an >>>>> SDO wants this". They fall under the "meaningless words" >>>>> category and I'm incapable of discussing them because they come >>>>> with voting attitudes. They all need to be justified if the WG >>>>> wants to have a technical _discussion_. >>>>> >>>>> Here are my reasons: >>>>> >>>>> 1. The HA does not know whether a CoA is tied to a certain access >>>>> technology. It is one thing for the HA to send a message saying >>>>> "forward port 80 traffic on a wifi link" (a policy) and a >>>>> completely different thing to say "forward port 80 traffic using CoA = 3ffe::1" >>>>> (a rule). >>>>> >>>>> 2. You might argue that the HA can be told by the MN that 3ffe::1 >>>>> is tied to a wifi access, so what's the problem now? The problem is >>>>> that the HA has no idea about dynamic changes on that wifi link. It >>>>> doesn't know if it's congested, it doesn't know what application is >>>>> using port 80 (it doesn't have to be web traffic) or port 8000 for >>>>> that matter and doesn't even know if the AP of that wifi link works >>>>> at all. >>>>> Finally, it >>>>> doesn't know the user's policies or other admin policies for that MN. >>>>> This type of information needs to be sent regularly because it >>>>> changes all the time and requires serious cross layer integration >>>>> including sometimes layer 8 integration! It's completely impractical. >>>>> >>>>> 3. If the HA installed rules in the MN, what happens if the MN >>>>> wants to change those rules. Say the wifi link went down, or the >>>>> MN's wifi interface went down and it wants to move that traffic to >>>>> another interface. Would the HA reject such move? Does the MN have >>>>> to justify to the HA why it needs to move traffic? Does that >>>>> involve writing a letter perhaps? >>>>> If you say "well in that case, the HA should let the MN move the >>>>> traffic" >>>>> then I'll ask you: what's the point of having the HA install this >>>>> stuff if it has no authority and how does it know the reason for >>>>> the MN's movement of the flow? >>>>> The way to control how users do things is to incentivise them with >>>>> charging models and show them that things work better on certain >>>>> technologies, not by installing rules that can't be followed. It's >>>>> a broken mindset and we've known that it's broken for a long time. >>>>> >>>>> 4. Some people mentioned that the HA should be able to revoke flows >>>>> on the MN. I'm perfectly fine with that, just extend the binding >>>>> revocation draft to handle flows and the rest is pretty straight >>>>> forward. >>>>> >>>>> Finally, I'll indulge in a true story that happened to me a few >>>>> years ago when I found that my wifi link wasn't working in a hotel >>>>> (no >>>>> radio) >>>>> and called the help desk. He insisted that the link was up an I >>>>> insisted that it wasn't. When I asked him to tell me how he knows >>>>> the link is up he said: I can ping the AP! Of course after another >>>>> 5 minutes of trying to convince him that pinging the AP doesn't >>>>> mean the radio is actually working he sent someone to the hotel who >>>>> in turn realised that the radio was not working. >>>>> For those people who want rules to be transferred from the HA to >>>>> the MN, please think of your HA as this help desk person, i.e. it >>>>> has no clue about what's happening at the other end. >>>>> >>>>> I hope this helps with the realisation that decisions can't be made >>>>> here based on voting and that there is little merit to transferring >>>>> rules from the HA to the MN. Policies can be transferred without >>>>> any problems, but not rules. >>>>> >>>>> Hesham >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > From yuri.ismailov@ericsson.com Wed Jun 3 02:35:52 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 629FF3A6B41 for ; Wed, 3 Jun 2009 02:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.916 X-Spam-Level: X-Spam-Status: No, score=-7.916 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 jo9bRzXPWbif for ; Wed, 3 Jun 2009 02:35:50 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C936328C192 for ; Wed, 3 Jun 2009 02:34:50 -0700 (PDT) X-AuditID: c1b4fb3e-b7b4bae00000395e-cf-4a2643baba72 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 7B.0C.14686.AB3462A4; Wed, 3 Jun 2009 11:34:50 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jun 2009 11:33:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 11:33:29 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKg References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 03 Jun 2009 09:33:30.0394 (UTC) FILETIME=[5B0C6FA0:01C9E42E] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 09:35:52 -0000 Hesham, Whenever we talk about sending additional information, the "waste of = bandwidth" can be brought up. So I do not have an answer for that = besides speculations around it. Otherwise, we can go far beyond normal = logic:-) Flow mobility support requires additional signaling - waste of = bandwidth and what are benefits? Mobility support requires additional = signaling ..... Any new feature will require additional signaling..... Speaking about benefits, everybody who knows the area is capable of = turning things up side down. I assume it is subjective standpoint of = considering things as benefits or disadvantages and all is about to = agree or disagree. For me those I wrote about are benefits or potential = benefits if you want. One important thing in the discussion, although mentioned, but forgotten = later is that by making rules distribution one way only, we do create = limitation for benefits, or potential benefits if this sounds better. /yuri -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Wednesday, June 03, 2009 10:10 AM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings Yuri, I can't parse those events you refer to. I'l answer both emails here. = First the events you refer to: >> - network condition towards CN(s) >> - the sum of number of hops between MN -> HA and HA -> CN =3D> What's the event? A change in those conditions? The MN knows the = conditions of the e2e path as well as or better than the HA. What is the = benefit of having the HA send a hint and how reliable is that hint = anyway? >> - Access provider (any access, not necessarily wireless) who offeres=20 >> HA services preferences change =3D> Preferences change to what?? How does it know if such change works = for the MN at all? This is way too vague to be able to discuss = tradeoffs. >> - Change of the access provider traffic to another backbone provider=20 >> due to the time of the day. >> - Traffic condition on HA interface, which accepts traffic from MN if = >> MN sends on some particular local interface =3D> These are path changes. The HA has _no idea_ how such a change = affects each MN/CN combination and it's "hint" can cause more problems = than it solves. BTW, if you're talking about hints then we're no longer = talking about installing bindings in the MN. This is a different topic. = MIP doesn't transfer hints, it pretty much sends "orders" from one end = to another. Now to the actions required by the MN: > - reject, > - re-evaluate and reject > - re-evaluate and accept > - accept =3D> First, by assuming that the MN can reject the "hint" as you call it = you invalidate the whole argument for the HA to install rules. Rejecting = a hint or even evaluating it means that the MN knows more. Therefore, = the HA's hint is a complete waste of bandwidth. I'm still confused about the _benefits_ you see here. Or are you = assuming that the MN can't know those hints without the HA's = involvement? But if you're assuming that, then how can it reject the = hints? This whole proposal makes no sense to me at all. Not to mention = the complexity you implicitly assume in order to generate those, = hopefully reliable, hints. Hesham On 3/06/09 5:23 PM, "Yuri Ismailov" wrote: > Hesham, >=20 > In my view these are events not scenarious. These events are known by=20 > HA but not MN. If HA acts upon events, given that it knows somewhat=20 > more about MN, not only IP addresses, it (HA) can generate new rules=20 > and send them as hint to MN. Back again, MN has four options: >=20 > The benefit will be obviously that the new rules (if accepted) may=20 > llead to a better overall communication characteristics. >=20 > /yuri >=20 >=20 > =3D> I'm trying to understand what you mean above. These are all=20 > scenarios, the question is: What is the benefit for the HA to transfer = > rules? The HA will not know the path between the MN and CN more than=20 > either node does. So I don't understand what _benefits_ you see here. >=20 > Hesham >=20 >>=20 >> Pretty much sure that there are more examples and I encourage to=20 >> think about those not from MN point of view but rather from the HA=20 >> service provider. >>=20 >> /yuri >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Wednesday, June 03, 2009 8:41 AM >> To: Yuri Ismailov; Nicolas Montavont;=20 >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of=20 >> flowbindings >>=20 >> Yuri, >>=20 >> It is just rules TRANSFER which is the matter of MIP. So where >>> is the logic when saying that MN to HA rules transfer is a practical = >>> engineering and HA to MN is an academic interest? >>=20 >> =3D> I think we've (I'm including myself) highlighted several reasons = >> for why it makes little sense to transfer rules from HA to MN.=20 >> Instead of rat-holing on theory Vs practice, you (or others=20 >> advocating the other direction) need to come up with reasons for=20 >> doing things this way. This way we can think like engineers about = tradeoffs. >> Absent that, I don't see any point in having theory Vs practice high=20 >> level discussions, which will lead nowhere. >>=20 >> Hesham >>=20 >>=20 >>>=20 >>> Regards >>> Yuri >>>=20 >>> -----Original Message----- >>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>> Sent: Tuesday, June 02, 2009 5:47 PM >>> To: pierrick.seite@orange-ftgroup.com >>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>> flowbindings >>>=20 >>> Hi Pierrick, >>>=20 >>> On Jun 2, 2009, at 4:11 PM, = wrote: >>>=20 >>>>=20 >>>> Hi all, >>>>=20 >>>> Please see inline comment. >>>>=20 >>>> Regards, >>>> Pierrick >>>>=20 >>>>> ________________________________________ >>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la=20 >>>>> part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 : >>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important considerations=20 >>>>> for directionality of flowbindings >>>>>=20 >>>>> Hesham, >>>>> This is nice story and makes some sense for the discssion, however = >>>>> some details are ommited. In your adventure with the helpdesk, it=20 >>>>> (the >>>>> helpdesk) is a third party service and thus your conclusions make=20 >>>>> sence. >>>>> Think of the situation when superior of a heldesk person will tell = >>>>> him/her to check access point in some room. Would it be the same=20 >>>>> reaction? I assume not. By that I mean that if, for example, I'll=20 >>>>> install home agent in my home network, I can make it know anything = >>>>> I want about MN, and more intresting is that how I will do it,=20 >>>>> does not require any standardization. >>>>> In other words, I'm superior of my HA. >>>>> This situation is not unthinkable, I personally believe that this=20 >>>>> is much more efficient way of using HA fnctionality as opposed to=20 >>>>> big service providers who will have to fight with scalability and=20 >>>>> performance. >>>>> However, one does not exclude another. >>>>> Difference between policies and rules is a convertion step. >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> The difference between policy and rules is not only a matter of=20 >>>> conversion. A policy, is a static, or quasi-static, set of guidance = >>>> for the MN (e.g use access network X for application type A,...)=20 >>>> while a rule update requires to be more dynamic. I mean: eventually = >>>> a policy could be updated depending on network condition (e.g if X=20 >>>> overloaded, use access network Y for application type A,...) but a=20 >>>> rule reacts on local triggers (e.g. modification of the radio link >>>> quality) with a shorter period of variation. So, IMHO, there is no=20 >>>> requirement for updating policy on a short period and out-of-band=20 >>>> mechanism can be used (e.g. IEEE 802.21 in push mode,...). >>>=20 >>> Fully agree! >>> This is why I do not support the exchange of rules from the HA to = the MN. >>> Policies may be exchanged from the HA to the MN, but MIP is=20 >>> definitely not the protocol to transport them. >>>=20 >>> Nicolas >>>=20 >>>>=20 >>>>=20 >>>> My 2 cents... >>>>=20 >>>>>=20 >>>>> Is there any reason to restrict where such convertion takes place? >>>>> True >>>>> that a HA does not know what is going on in the access network, on = >>>>> the other hand HA may know what is the network condition between=20 >>>>> HA and correspondent node. Either of this information is=20 >>>>> important, if not equally important. >>>>> It is not really difficult to let an MN to reject rules sent by=20 >>>>> HA, which in my view would be quite natural. This implies that HA=20 >>>>> must follow the rules installed by MN until explicit acceptance=20 >>>>> has been received from MN. >>>>> Such procedure is very similar to an MN beahviour when initiating=20 >>>>> new BU, where MN is not supposed to send any traffic before BU=20 >>>>> confirmation. >>>>> BTW, what is the numerical representation of "rough consensus"? I=20 >>>>> assume is when majority is for, is it so? >>>>> Yuri >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 >>>>> Behalf Of Hesham Soliman >>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>> To: mext >>>>> Subject: [MEXT] Important considerations for directionality of=20 >>>>> flow bindings >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> I've always been a fan of the IETF's tradition of rough concensus=20 >>>>> (as opposed to voting). To me, this implies that you need to get=20 >>>>> your point across and get other people to see that point of view. >>>>> As opposed to other organisations that require their members to=20 >>>>> vote and end up with rigid political positions. >>>>>=20 >>>>> The chairs asked us about the directionality question of the flows = >>>>> bindings. >>>>> On the charter question, I said that the charter doesn't need to=20 >>>>> mention how a solution should work, but rather what problem needs=20 >>>>> to be solved. >>>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>>> transferring rules "between" the MN and HA without mentioning = directions. >>>>>=20 >>>>> Nevertheless, we still need to agree on identifying the=20 >>>>> requirement for the solution. And when it comes to this, I'm=20 >>>>> strongly against voting and I'll practice this by explaining in=20 >>>>> this email why I think rules can not be transferred from the HA to = >>>>> the MN and that the only direction that makes sense in MIP is=20 >>>>> MN->HA. I'll deliberately ignore arguments like "some people want=20 >>>>> this" or "an SDO wants this". They fall under the "meaningless = words" >>>>> category and I'm incapable of discussing them because they come=20 >>>>> with voting attitudes. They all need to be justified if the WG=20 >>>>> wants to have a technical _discussion_. >>>>>=20 >>>>> Here are my reasons: >>>>>=20 >>>>> 1. The HA does not know whether a CoA is tied to a certain access=20 >>>>> technology. It is one thing for the HA to send a message saying=20 >>>>> "forward port 80 traffic on a wifi link" (a policy) and a=20 >>>>> completely different thing to say "forward port 80 traffic using=20 >>>>> CoA 3ffe::1" >>>>> (a rule). >>>>>=20 >>>>> 2. You might argue that the HA can be told by the MN that 3ffe::1=20 >>>>> is tied to a wifi access, so what's the problem now? The problem=20 >>>>> is that the HA has no idea about dynamic changes on that wifi=20 >>>>> link. It doesn't know if it's congested, it doesn't know what=20 >>>>> application is using port 80 (it doesn't have to be web traffic)=20 >>>>> or port 8000 for that matter and doesn't even know if the AP of=20 >>>>> that wifi link works at all. >>>>> Finally, it >>>>> doesn't know the user's policies or other admin policies for that = MN. >>>>> This type of information needs to be sent regularly because it=20 >>>>> changes all the time and requires serious cross layer integration=20 >>>>> including sometimes layer 8 integration! It's completely = impractical. >>>>>=20 >>>>> 3. If the HA installed rules in the MN, what happens if the MN=20 >>>>> wants to change those rules. Say the wifi link went down, or the=20 >>>>> MN's wifi interface went down and it wants to move that traffic to = >>>>> another interface. Would the HA reject such move? Does the MN have = >>>>> to justify to the HA why it needs to move traffic? Does that=20 >>>>> involve writing a letter perhaps? >>>>> If you say "well in that case, the HA should let the MN move the=20 >>>>> traffic" >>>>> then I'll ask you: what's the point of having the HA install this=20 >>>>> stuff if it has no authority and how does it know the reason for=20 >>>>> the MN's movement of the flow? >>>>> The way to control how users do things is to incentivise them with = >>>>> charging models and show them that things work better on certain=20 >>>>> technologies, not by installing rules that can't be followed. It's = >>>>> a broken mindset and we've known that it's broken for a long time. >>>>>=20 >>>>> 4. Some people mentioned that the HA should be able to revoke=20 >>>>> flows on the MN. I'm perfectly fine with that, just extend the=20 >>>>> binding revocation draft to handle flows and the rest is pretty=20 >>>>> straight forward. >>>>>=20 >>>>> Finally, I'll indulge in a true story that happened to me a few=20 >>>>> years ago when I found that my wifi link wasn't working in a hotel = >>>>> (no >>>>> radio) >>>>> and called the help desk. He insisted that the link was up an I=20 >>>>> insisted that it wasn't. When I asked him to tell me how he knows=20 >>>>> the link is up he said: I can ping the AP! Of course after another >>>>> 5 minutes of trying to convince him that pinging the AP doesn't=20 >>>>> mean the radio is actually working he sent someone to the hotel=20 >>>>> who in turn realised that the radio was not working. >>>>> For those people who want rules to be transferred from the HA to=20 >>>>> the MN, please think of your HA as this help desk person, i.e. it=20 >>>>> has no clue about what's happening at the other end. >>>>>=20 >>>>> I hope this helps with the realisation that decisions can't be=20 >>>>> made here based on voting and that there is little merit to=20 >>>>> transferring rules from the HA to the MN. Policies can be=20 >>>>> transferred without any problems, but not rules. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>=20 >>=20 >>=20 >=20 >=20 From yuri.ismailov@ericsson.com Wed Jun 3 02:37:00 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524E43A6BAF for ; Wed, 3 Jun 2009 02:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.963 X-Spam-Level: X-Spam-Status: No, score=-7.963 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 tRMKCrAmVPtO for ; Wed, 3 Jun 2009 02:36:58 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B8FA53A6B41 for ; Wed, 3 Jun 2009 02:36:56 -0700 (PDT) X-AuditID: c1b4fb3c-b7b14ae0000039d7-69-4a2644298929 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id D7.32.14807.924462A4; Wed, 3 Jun 2009 11:36:41 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jun 2009 11:35:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 11:35:53 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnkLZP1UuwHi6yCTkSGl8joeiKQRAAAM+TQ References: From: "Yuri Ismailov" To: "George Tsirtsis" X-OriginalArrivalTime: 03 Jun 2009 09:35:54.0672 (UTC) FILETIME=[B10B8300:01C9E42E] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 09:37:00 -0000 True, I would say progress is NULL. /yuri=20 -----Original Message----- From: George Tsirtsis [mailto:tsirtsis@googlemail.com]=20 Sent: Wednesday, June 03, 2009 11:17 AM To: Yuri Ismailov Cc: Hesham Soliman; Nicolas Montavont; = pierrick.seite@orange-ftgroup.com; mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings I only referred to your employment regarding access you might have to = credible and relevant information. I hope you did not take it the wrong = way. Corporate and residential scenarios are even less relevant. An HA at = home or at the office can know even less relevant information than an HA = in say a cellular system, when the mobile is roaming somewhere on the = Internet. But we keep dancing around the same arguments...no much progress. George On Wed, Jun 3, 2009 at 8:34 AM, Yuri Ismailov = wrote: > George, > I do not think that my employment matters for this discussion. > I suggest we focus then on corporate scenarious or residential=20 > networks, which would have similar access provider functions which I=20 > described eralier /yuri > > -----Original Message----- > From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > Sent: Wednesday, June 03, 2009 9:18 AM > To: Yuri Ismailov > Cc: Hesham Soliman; Nicolas Montavont;=20 > pierrick.seite@orange-ftgroup.com; mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of=20 > flowbindings > > Yuri, > > Since you are working for a vendor to cellular operators it should be = trivial for you to check what the bottlenecks in cellular and other = wireless networks are. > > In cellular, by far the biggest bottleneck is the wireless link i.e., = the airlink between the mobile and the base station (BS) / access point = (AP). > The next bottleneck is the backhaul link connecting the BS/AP to the = aggregation router/switch depending on RAN architecture. > > These two links are simply too expensive to overdimention; the former = due to spectrum cost/constraints, and the latter due to the high = cost/volume of last-mile wires required to go to all the BS/AP. > > In all networks, technologies, and deployments I have been involved = with, the rest of the network is considered pretty much to be = overdimentioned. This is why all the conditions to which you claim the = HA may have better view of (even if one considers the HA to somehow know = the condition of the whole network, which of course is nonsense), are in = any case not relevant in practice. And they are certainly not relevant = to the uplink traffic sent by the mobile over the first 2 links, which = are also the only relevant bottlenecks in the system. > > George > > On Wed, Jun 3, 2009 at 8:00 AM, Yuri Ismailov = wrote: >> Hesham, >> "Academic interest" is not my argument and I agree that this kind of = discussion will take us nowhere. You withdrew this statement from the = context. >> Some examples: >> >> - network condition towards CN(s) >> - the sum of number of hops between MN -> HA and HA -> CN >> - Access provider (any access, not necessarily wireless) who offeres=20 >> HA services preferences change >> - Change of the access provider traffic to another backbone provider = due to the time of the day. >> - Traffic condition on HA interface, which accepts traffic from MN if = >> MN sends on some particular local interface >> >> Pretty much sure that there are more examples and I encourage to = think about those not from MN point of view but rather from the HA = service provider. >> >> /yuri >> >> >> >> >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Wednesday, June 03, 2009 8:41 AM >> To: Yuri Ismailov; Nicolas Montavont;=20 >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of=20 >> flowbindings >> >> Yuri, >> >> =A0It is just rules TRANSFER which is the matter of MIP. So where >>> is the logic when saying that MN to HA rules transfer is a practical = >>> engineering and HA to MN is an academic interest? >> >> =3D> I think we've (I'm including myself) highlighted several reasons = for why it makes little sense to transfer rules from HA to MN. Instead = of rat-holing on theory Vs practice, you (or others advocating the other = direction) need to come up with reasons for doing things this way. This = way we can think like engineers about tradeoffs. >> Absent that, I don't see any point in having theory Vs practice high = level discussions, which will lead nowhere. >> >> Hesham >> >> >>> >>> Regards >>> Yuri >>> >>> -----Original Message----- >>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>> Sent: Tuesday, June 02, 2009 5:47 PM >>> To: pierrick.seite@orange-ftgroup.com >>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>> flowbindings >>> >>> Hi Pierrick, >>> >>> On Jun 2, 2009, at 4:11 PM, = wrote: >>> >>>> >>>> Hi all, >>>> >>>> Please see inline comment. >>>> >>>> Regards, >>>> Pierrick >>>> >>>>> ________________________________________ >>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la=20 >>>>> part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 : >>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important considerations=20 >>>>> for directionality of flowbindings >>>>> >>>>> Hesham, >>>>> This is nice story and makes some sense for the discssion, however = >>>>> some details are ommited. In your adventure with the helpdesk, it=20 >>>>> (the >>>>> helpdesk) is a third party service and thus your conclusions make=20 >>>>> sence. >>>>> Think of the situation when superior of a heldesk person will tell = >>>>> him/her to check access point in some room. Would it be the same=20 >>>>> reaction? I assume not. By that I mean that if, for example, I'll=20 >>>>> install home agent in my home network, I can make it know anything = >>>>> I want about MN, and more intresting is that how I will do it,=20 >>>>> does not require any standardization. >>>>> In other words, I'm superior of my HA. >>>>> This situation is not unthinkable, I personally believe that this=20 >>>>> is much more efficient way of using HA fnctionality as opposed to=20 >>>>> big service providers who will have to fight with scalability and=20 >>>>> performance. >>>>> However, one does not exclude another. >>>>> Difference between policies and rules is a convertion step. >>>>> >>>>> >>>> >>>> >>>> The difference between policy and rules is not only a matter of=20 >>>> conversion. A policy, is a static, or quasi-static, set of guidance = >>>> for the MN (e.g use access network X for application type A,...)=20 >>>> while a rule update requires to be more dynamic. I mean: eventually = >>>> a policy could be updated depending on network condition (e.g if X=20 >>>> overloaded, use access network Y for application type A,...) but a=20 >>>> rule reacts on local triggers (e.g. modification of the radio link >>>> quality) with a shorter period of variation. So, IMHO, there is no=20 >>>> requirement for updating policy on a short period and out-of-band=20 >>>> mechanism can be used (e.g. IEEE 802.21 in push mode,...). >>> >>> Fully agree! >>> This is why I do not support the exchange of rules from the HA to = the MN. >>> Policies may be exchanged from the HA to the MN, but MIP is=20 >>> definitely not the protocol to transport them. >>> >>> Nicolas >>> >>>> >>>> >>>> My 2 cents... >>>> >>>>> >>>>> Is there any reason to restrict where such convertion takes place? >>>>> True >>>>> that a HA does not know what is going on in the access network, on = >>>>> the other hand HA may know what is the network condition between=20 >>>>> HA and correspondent node. Either of this information is=20 >>>>> important, if not equally important. >>>>> It is not really difficult to let an MN to reject rules sent by=20 >>>>> HA, which in my view would be quite natural. This implies that HA=20 >>>>> must follow the rules installed by MN until explicit acceptance=20 >>>>> has been received from MN. >>>>> Such procedure is very similar to an MN beahviour when initiating=20 >>>>> new BU, where MN is not supposed to send any traffic before BU=20 >>>>> confirmation. >>>>> BTW, what is the numerical representation of "rough consensus"? I=20 >>>>> assume is when majority is for, is it so? >>>>> Yuri >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 >>>>> Behalf Of Hesham Soliman >>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>> To: mext >>>>> Subject: [MEXT] Important considerations for directionality of=20 >>>>> flow bindings >>>>> >>>>> Hi all, >>>>> >>>>> I've always been a fan of the IETF's tradition of rough concensus=20 >>>>> (as opposed to voting). To me, this implies that you need to get=20 >>>>> your point across and get other people to see that point of view. >>>>> As opposed to other organisations that require their members to=20 >>>>> vote and end up with rigid political positions. >>>>> >>>>> The chairs asked us about the directionality question of the flows = >>>>> bindings. >>>>> On the charter question, I said that the charter doesn't need to=20 >>>>> mention how a solution should work, but rather what problem needs=20 >>>>> to be solved. >>>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>>> transferring rules "between" the MN and HA without mentioning = directions. >>>>> >>>>> Nevertheless, we still need to agree on identifying the=20 >>>>> requirement for the solution. And when it comes to this, I'm=20 >>>>> strongly against voting and I'll practice this by explaining in=20 >>>>> this email why I think rules can not be transferred from the HA to = >>>>> the MN and that the only direction that makes sense in MIP is=20 >>>>> MN->HA. I'll deliberately ignore arguments like "some people want=20 >>>>> this" or "an SDO wants this". They fall under the "meaningless = words" >>>>> category and I'm incapable of discussing them because they come=20 >>>>> with voting attitudes. They all need to be justified if the WG=20 >>>>> wants to have a technical _discussion_. >>>>> >>>>> Here are my reasons: >>>>> >>>>> 1. The HA does not know whether a CoA is tied to a certain access=20 >>>>> technology. It is one thing for the HA to send a message saying=20 >>>>> "forward port 80 traffic on a wifi link" (a policy) and a=20 >>>>> completely different thing to say "forward port 80 traffic using = CoA 3ffe::1" >>>>> (a rule). >>>>> >>>>> 2. You might argue that the HA can be told by the MN that 3ffe::1=20 >>>>> is tied to a wifi access, so what's the problem now? The problem=20 >>>>> is that the HA has no idea about dynamic changes on that wifi=20 >>>>> link. It doesn't know if it's congested, it doesn't know what=20 >>>>> application is using port 80 (it doesn't have to be web traffic)=20 >>>>> or port 8000 for that matter and doesn't even know if the AP of=20 >>>>> that wifi link works at all. >>>>> Finally, it >>>>> doesn't know the user's policies or other admin policies for that = MN. >>>>> This type of information needs to be sent regularly because it=20 >>>>> changes all the time and requires serious cross layer integration=20 >>>>> including sometimes layer 8 integration! It's completely = impractical. >>>>> >>>>> 3. If the HA installed rules in the MN, what happens if the MN=20 >>>>> wants to change those rules. Say the wifi link went down, or the=20 >>>>> MN's wifi interface went down and it wants to move that traffic to = >>>>> another interface. Would the HA reject such move? Does the MN have = >>>>> to justify to the HA why it needs to move traffic? Does that=20 >>>>> involve writing a letter perhaps? >>>>> If you say "well in that case, the HA should let the MN move the=20 >>>>> traffic" >>>>> then I'll ask you: what's the point of having the HA install this=20 >>>>> stuff if it has no authority and how does it know the reason for=20 >>>>> the MN's movement of the flow? >>>>> The way to control how users do things is to incentivise them with = >>>>> charging models and show them that things work better on certain=20 >>>>> technologies, not by installing rules that can't be followed. It's = >>>>> a broken mindset and we've known that it's broken for a long time. >>>>> >>>>> 4. Some people mentioned that the HA should be able to revoke=20 >>>>> flows on the MN. I'm perfectly fine with that, just extend the=20 >>>>> binding revocation draft to handle flows and the rest is pretty=20 >>>>> straight forward. >>>>> >>>>> Finally, I'll indulge in a true story that happened to me a few=20 >>>>> years ago when I found that my wifi link wasn't working in a hotel = >>>>> (no >>>>> radio) >>>>> and called the help desk. He insisted that the link was up an I=20 >>>>> insisted that it wasn't. When I asked him to tell me how he knows=20 >>>>> the link is up he said: I can ping the AP! Of course after another >>>>> 5 minutes of trying to convince him that pinging the AP doesn't=20 >>>>> mean the radio is actually working he sent someone to the hotel=20 >>>>> who in turn realised that the radio was not working. >>>>> For those people who want rules to be transferred from the HA to=20 >>>>> the MN, please think of your HA as this help desk person, i.e. it=20 >>>>> has no clue about what's happening at the other end. >>>>> >>>>> I hope this helps with the realisation that decisions can't be=20 >>>>> made here based on voting and that there is little merit to=20 >>>>> transferring rules from the HA to the MN. Policies can be=20 >>>>> transferred without any problems, but not rules. >>>>> >>>>> Hesham >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > From hesham@elevatemobile.com Wed Jun 3 02:47:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235A23A6A8D for ; Wed, 3 Jun 2009 02:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 zNol5b4E3VDY for ; Wed, 3 Jun 2009 02:47:23 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id F08933A6862 for ; Wed, 3 Jun 2009 02:47:22 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MBn3w-0006QC-1L; Wed, 03 Jun 2009 19:47:13 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Wed, 03 Jun 2009 19:47:03 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILU= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 09:47:25 -0000 On 3/06/09 7:33 PM, "Yuri Ismailov" wrote: > Hesham, >=20 > Whenever we talk about sending additional information, the "waste of > bandwidth" can be brought up. So I do not have an answer for that besides > speculations around it. =3D> no no, I don't mean it literally, I mean that the message doesn't do anything, i.e. Has no benefit. >=20 > Speaking about benefits, everybody who knows the area is capable of turni= ng > things up side down. I assume it is subjective standpoint of considering > things as benefits or disadvantages and all is about to agree or disagree= . =3D> That's fine, I'm asking for benefits in your opinion not someone else's. It's impossible to discuss this if I can't see any benefits because you didn't send any. What you sent were actions that can be done by the HA and = I responded by saying that the same (or more) information is available to the MN. Therefore, if you think there are additional benefits to doing this in the HA then you need to tell us. The bottom line is this: MIP works by letting the MN install bindings in th= e HA. If you want things to work in reverse you need to justify it. I can't see any justifications because you're not answering my questions on your scenarios. So, count me out on the reverse direction :). For=20 > me those I wrote about are benefits or potential benefits if you want. =3D> No you didn't. You wrote about things that can be done. Many things can be done by many entities, the question is why the HA and not the MN. > One important thing in the discussion, although mentioned, but forgotten = later > is that by making rules distribution one way only, we do create limitatio= n for > benefits, or potential benefits if this sounds better. =3D> Well, we won't know what we're missing unless someone tells us. So far n= o one has mentioned the advantages of doing things in the reverse direction. There is always something missing from a protocol (it's engineering), the question us whether it's significant or worth the trouble. Hesham >=20 > /yuri >=20 >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Wednesday, June 03, 2009 10:10 AM > To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of > flowbindings >=20 > Yuri, >=20 > I can't parse those events you refer to. I'l answer both emails here. Fir= st > the events you refer to: >=20 >>> - network condition towards CN(s) >>> - the sum of number of hops between MN -> HA and HA -> CN >=20 > =3D> What's the event? A change in those conditions? The MN knows the condi= tions > of the e2e path as well as or better than the HA. What is the benefit of > having the HA send a hint and how reliable is that hint anyway? >=20 >>> - Access provider (any access, not necessarily wireless) who offeres >>> HA services preferences change >=20 > =3D> Preferences change to what?? How does it know if such change works for= the > MN at all? This is way too vague to be able to discuss tradeoffs. >=20 >>> - Change of the access provider traffic to another backbone provider >>> due to the time of the day. >>> - Traffic condition on HA interface, which accepts traffic from MN if >>> MN sends on some particular local interface >=20 > =3D> These are path changes. The HA has _no idea_ how such a change affects= each > MN/CN combination and it's "hint" can cause more problems than it solves.= BTW, > if you're talking about hints then we're no longer talking about installi= ng > bindings in the MN. This is a different topic. MIP doesn't transfer hints= , it > pretty much sends "orders" from one end to another. >=20 > Now to the actions required by the MN: >=20 >> - reject, >> - re-evaluate and reject >> - re-evaluate and accept >> - accept >=20 > =3D> First, by assuming that the MN can reject the "hint" as you call it yo= u > invalidate the whole argument for the HA to install rules. Rejecting a hi= nt or > even evaluating it means that the MN knows more. Therefore, the HA's hint= is a > complete waste of bandwidth. >=20 > I'm still confused about the _benefits_ you see here. Or are you assuming= that > the MN can't know those hints without the HA's involvement? But if you're > assuming that, then how can it reject the hints? This whole proposal make= s no > sense to me at all. Not to mention the complexity you implicitly assume i= n > order to generate those, hopefully reliable, hints. >=20 > Hesham >=20 >=20 > On 3/06/09 5:23 PM, "Yuri Ismailov" wrote: >=20 >> Hesham, >>=20 >> In my view these are events not scenarious. These events are known by >> HA but not MN. If HA acts upon events, given that it knows somewhat >> more about MN, not only IP addresses, it (HA) can generate new rules >> and send them as hint to MN. Back again, MN has four options: >>=20 >> The benefit will be obviously that the new rules (if accepted) may >> llead to a better overall communication characteristics. >>=20 >> /yuri >>=20 >>=20 >> =3D> I'm trying to understand what you mean above. These are all >> scenarios, the question is: What is the benefit for the HA to transfer >> rules? The HA will not know the path between the MN and CN more than >> either node does. So I don't understand what _benefits_ you see here. >>=20 >> Hesham >>=20 >>>=20 >>> Pretty much sure that there are more examples and I encourage to >>> think about those not from MN point of view but rather from the HA >>> service provider. >>>=20 >>> /yuri >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Wednesday, June 03, 2009 8:41 AM >>> To: Yuri Ismailov; Nicolas Montavont; >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of >>> flowbindings >>>=20 >>> Yuri, >>>=20 >>> It is just rules TRANSFER which is the matter of MIP. So where >>>> is the logic when saying that MN to HA rules transfer is a practical >>>> engineering and HA to MN is an academic interest? >>>=20 >>> =3D> I think we've (I'm including myself) highlighted several reasons >>> for why it makes little sense to transfer rules from HA to MN. >>> Instead of rat-holing on theory Vs practice, you (or others >>> advocating the other direction) need to come up with reasons for >>> doing things this way. This way we can think like engineers about trade= offs. >>> Absent that, I don't see any point in having theory Vs practice high >>> level discussions, which will lead nowhere. >>>=20 >>> Hesham >>>=20 >>>=20 >>>>=20 >>>> Regards >>>> Yuri >>>>=20 >>>> -----Original Message----- >>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>> To: pierrick.seite@orange-ftgroup.com >>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of >>>> flowbindings >>>>=20 >>>> Hi Pierrick, >>>>=20 >>>> On Jun 2, 2009, at 4:11 PM, wrote: >>>>=20 >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> Please see inline comment. >>>>>=20 >>>>> Regards, >>>>> Pierrick >>>>>=20 >>>>>> ________________________________________ >>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la >>>>>> part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 : >>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important considerations >>>>>> for directionality of flowbindings >>>>>>=20 >>>>>> Hesham, >>>>>> This is nice story and makes some sense for the discssion, however >>>>>> some details are ommited. In your adventure with the helpdesk, it >>>>>> (the >>>>>> helpdesk) is a third party service and thus your conclusions make >>>>>> sence. >>>>>> Think of the situation when superior of a heldesk person will tell >>>>>> him/her to check access point in some room. Would it be the same >>>>>> reaction? I assume not. By that I mean that if, for example, I'll >>>>>> install home agent in my home network, I can make it know anything >>>>>> I want about MN, and more intresting is that how I will do it, >>>>>> does not require any standardization. >>>>>> In other words, I'm superior of my HA. >>>>>> This situation is not unthinkable, I personally believe that this >>>>>> is much more efficient way of using HA fnctionality as opposed to >>>>>> big service providers who will have to fight with scalability and >>>>>> performance. >>>>>> However, one does not exclude another. >>>>>> Difference between policies and rules is a convertion step. >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> The difference between policy and rules is not only a matter of >>>>> conversion. A policy, is a static, or quasi-static, set of guidance >>>>> for the MN (e.g use access network X for application type A,...) >>>>> while a rule update requires to be more dynamic. I mean: eventually >>>>> a policy could be updated depending on network condition (e.g if X >>>>> overloaded, use access network Y for application type A,...) but a >>>>> rule reacts on local triggers (e.g. modification of the radio link >>>>> quality) with a shorter period of variation. So, IMHO, there is no >>>>> requirement for updating policy on a short period and out-of-band >>>>> mechanism can be used (e.g. IEEE 802.21 in push mode,...). >>>>=20 >>>> Fully agree! >>>> This is why I do not support the exchange of rules from the HA to the = MN. >>>> Policies may be exchanged from the HA to the MN, but MIP is >>>> definitely not the protocol to transport them. >>>>=20 >>>> Nicolas >>>>=20 >>>>>=20 >>>>>=20 >>>>> My 2 cents... >>>>>=20 >>>>>>=20 >>>>>> Is there any reason to restrict where such convertion takes place? >>>>>> True >>>>>> that a HA does not know what is going on in the access network, on >>>>>> the other hand HA may know what is the network condition between >>>>>> HA and correspondent node. Either of this information is >>>>>> important, if not equally important. >>>>>> It is not really difficult to let an MN to reject rules sent by >>>>>> HA, which in my view would be quite natural. This implies that HA >>>>>> must follow the rules installed by MN until explicit acceptance >>>>>> has been received from MN. >>>>>> Such procedure is very similar to an MN beahviour when initiating >>>>>> new BU, where MN is not supposed to send any traffic before BU >>>>>> confirmation. >>>>>> BTW, what is the numerical representation of "rough consensus"? I >>>>>> assume is when majority is for, is it so? >>>>>> Yuri >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>>>> Behalf Of Hesham Soliman >>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>> To: mext >>>>>> Subject: [MEXT] Important considerations for directionality of >>>>>> flow bindings >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> I've always been a fan of the IETF's tradition of rough concensus >>>>>> (as opposed to voting). To me, this implies that you need to get >>>>>> your point across and get other people to see that point of view. >>>>>> As opposed to other organisations that require their members to >>>>>> vote and end up with rigid political positions. >>>>>>=20 >>>>>> The chairs asked us about the directionality question of the flows >>>>>> bindings. >>>>>> On the charter question, I said that the charter doesn't need to >>>>>> mention how a solution should work, but rather what problem needs >>>>>> to be solved. >>>>>> Hence, as far as the charter is concerned, I'm fine with >>>>>> transferring rules "between" the MN and HA without mentioning direct= ions. >>>>>>=20 >>>>>> Nevertheless, we still need to agree on identifying the >>>>>> requirement for the solution. And when it comes to this, I'm >>>>>> strongly against voting and I'll practice this by explaining in >>>>>> this email why I think rules can not be transferred from the HA to >>>>>> the MN and that the only direction that makes sense in MIP is >>>>>> MN->HA. I'll deliberately ignore arguments like "some people want >>>>>> this" or "an SDO wants this". They fall under the "meaningless words= " >>>>>> category and I'm incapable of discussing them because they come >>>>>> with voting attitudes. They all need to be justified if the WG >>>>>> wants to have a technical _discussion_. >>>>>>=20 >>>>>> Here are my reasons: >>>>>>=20 >>>>>> 1. The HA does not know whether a CoA is tied to a certain access >>>>>> technology. It is one thing for the HA to send a message saying >>>>>> "forward port 80 traffic on a wifi link" (a policy) and a >>>>>> completely different thing to say "forward port 80 traffic using >>>>>> CoA 3ffe::1" >>>>>> (a rule). >>>>>>=20 >>>>>> 2. You might argue that the HA can be told by the MN that 3ffe::1 >>>>>> is tied to a wifi access, so what's the problem now? The problem >>>>>> is that the HA has no idea about dynamic changes on that wifi >>>>>> link. It doesn't know if it's congested, it doesn't know what >>>>>> application is using port 80 (it doesn't have to be web traffic) >>>>>> or port 8000 for that matter and doesn't even know if the AP of >>>>>> that wifi link works at all. >>>>>> Finally, it >>>>>> doesn't know the user's policies or other admin policies for that MN= . >>>>>> This type of information needs to be sent regularly because it >>>>>> changes all the time and requires serious cross layer integration >>>>>> including sometimes layer 8 integration! It's completely impractical= . >>>>>>=20 >>>>>> 3. If the HA installed rules in the MN, what happens if the MN >>>>>> wants to change those rules. Say the wifi link went down, or the >>>>>> MN's wifi interface went down and it wants to move that traffic to >>>>>> another interface. Would the HA reject such move? Does the MN have >>>>>> to justify to the HA why it needs to move traffic? Does that >>>>>> involve writing a letter perhaps? >>>>>> If you say "well in that case, the HA should let the MN move the >>>>>> traffic" >>>>>> then I'll ask you: what's the point of having the HA install this >>>>>> stuff if it has no authority and how does it know the reason for >>>>>> the MN's movement of the flow? >>>>>> The way to control how users do things is to incentivise them with >>>>>> charging models and show them that things work better on certain >>>>>> technologies, not by installing rules that can't be followed. It's >>>>>> a broken mindset and we've known that it's broken for a long time. >>>>>>=20 >>>>>> 4. Some people mentioned that the HA should be able to revoke >>>>>> flows on the MN. I'm perfectly fine with that, just extend the >>>>>> binding revocation draft to handle flows and the rest is pretty >>>>>> straight forward. >>>>>>=20 >>>>>> Finally, I'll indulge in a true story that happened to me a few >>>>>> years ago when I found that my wifi link wasn't working in a hotel >>>>>> (no >>>>>> radio) >>>>>> and called the help desk. He insisted that the link was up an I >>>>>> insisted that it wasn't. When I asked him to tell me how he knows >>>>>> the link is up he said: I can ping the AP! Of course after another >>>>>> 5 minutes of trying to convince him that pinging the AP doesn't >>>>>> mean the radio is actually working he sent someone to the hotel >>>>>> who in turn realised that the radio was not working. >>>>>> For those people who want rules to be transferred from the HA to >>>>>> the MN, please think of your HA as this help desk person, i.e. it >>>>>> has no clue about what's happening at the other end. >>>>>>=20 >>>>>> I hope this helps with the realisation that decisions can't be >>>>>> made here based on voting and that there is little merit to >>>>>> transferring rules from the HA to the MN. Policies can be >>>>>> transferred without any problems, but not rules. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From yuri.ismailov@ericsson.com Wed Jun 3 03:52:51 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93D103A6BAF for ; Wed, 3 Jun 2009 03:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 eBzWMXEGTSEE for ; Wed, 3 Jun 2009 03:52:49 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 92D6E3A693D for ; Wed, 3 Jun 2009 03:52:34 -0700 (PDT) X-AuditID: c1b4fb3c-b7b14ae0000039d7-06-4a2655dd59c7 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 95.11.14807.DD5562A4; Wed, 3 Jun 2009 12:52:13 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jun 2009 12:52:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 12:52:00 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0A== References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 03 Jun 2009 10:52:01.0569 (UTC) FILETIME=[5320B110:01C9E439] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 10:52:51 -0000 Hesham, You are out:-) Still some answers, despite knowing that in your opinion they are not = benefits. First of all MIP will not be breaked if the rules will be sent in both = directions. - Access provider preferences relate to the use of backbone provider, = which may vary with the time of day. Changing backbone provider can make = quite big difference for commnication between HA (if HA service is = provided by the same access provider) and CN(s). The difference can be = expressed in, let's say, number of hops, load, possibly something else. = Such change is an event and may have an impact on the overall = communication. This can be told directly to MN or HA. Direct = communication to MN (if accepted as benefit:-)) in such case will need = standardization. Communication of this information to HA does not (I = consider this as a benefit). HA may act upon that event, and the rest = you know: rules in reverse direction. - Access provider may set up different parameters for traffic shaping = for each of HA interfaces. These preferences may vary independently of = change of backbone provider but dependently on the time of day. The rest = you know, whether it changes somebodies opinion. - I presume that in RO mode this is similar to HA mode, and I'm in when = it comes to send rules in reverse direction between CN and MN. Benefits = of doing that is that any change percieved by CN as important to react = upon can be expressed in proposal of new rules. The sources causing = changes may include but not limited to, are user, network managemnt = events, application generated events, etc. So feel free to consider this as benefits or not /yuri -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Wednesday, June 03, 2009 11:47 AM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings On 3/06/09 7:33 PM, "Yuri Ismailov" wrote: > Hesham, >=20 > Whenever we talk about sending additional information, the "waste of=20 > bandwidth" can be brought up. So I do not have an answer for that=20 > besides speculations around it. =3D> no no, I don't mean it literally, I mean that the message doesn't = do anything, i.e. Has no benefit. >=20 > Speaking about benefits, everybody who knows the area is capable of=20 > turning things up side down. I assume it is subjective standpoint of=20 > considering things as benefits or disadvantages and all is about to = agree or disagree. =3D> That's fine, I'm asking for benefits in your opinion not someone = else's. It's impossible to discuss this if I can't see any benefits because you = didn't send any. What you sent were actions that can be done by the HA = and I responded by saying that the same (or more) information is = available to the MN. Therefore, if you think there are additional = benefits to doing this in the HA then you need to tell us. The bottom line is this: MIP works by letting the MN install bindings in = the HA. If you want things to work in reverse you need to justify it. I = can't see any justifications because you're not answering my questions = on your scenarios. So, count me out on the reverse direction :). For=20 > me those I wrote about are benefits or potential benefits if you want. =3D> No you didn't. You wrote about things that can be done. Many things = can be done by many entities, the question is why the HA and not the MN. > One important thing in the discussion, although mentioned, but=20 > forgotten later is that by making rules distribution one way only, we=20 > do create limitation for benefits, or potential benefits if this = sounds better. =3D> Well, we won't know what we're missing unless someone tells us. So = far no one has mentioned the advantages of doing things in the reverse = direction. There is always something missing from a protocol (it's engineering), = the question us whether it's significant or worth the trouble. Hesham >=20 > /yuri >=20 >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Wednesday, June 03, 2009 10:10 AM > To: Yuri Ismailov; Nicolas Montavont;=20 > pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of=20 > flowbindings >=20 > Yuri, >=20 > I can't parse those events you refer to. I'l answer both emails here.=20 > First the events you refer to: >=20 >>> - network condition towards CN(s) >>> - the sum of number of hops between MN -> HA and HA -> CN >=20 > =3D> What's the event? A change in those conditions? The MN knows the=20 > conditions of the e2e path as well as or better than the HA. What is=20 > the benefit of having the HA send a hint and how reliable is that hint = anyway? >=20 >>> - Access provider (any access, not necessarily wireless) who offeres = >>> HA services preferences change >=20 > =3D> Preferences change to what?? How does it know if such change = works=20 > for the MN at all? This is way too vague to be able to discuss = tradeoffs. >=20 >>> - Change of the access provider traffic to another backbone provider = >>> due to the time of the day. >>> - Traffic condition on HA interface, which accepts traffic from MN=20 >>> if MN sends on some particular local interface >=20 > =3D> These are path changes. The HA has _no idea_ how such a change=20 > affects each MN/CN combination and it's "hint" can cause more problems = > than it solves. BTW, if you're talking about hints then we're no=20 > longer talking about installing bindings in the MN. This is a=20 > different topic. MIP doesn't transfer hints, it pretty much sends = "orders" from one end to another. >=20 > Now to the actions required by the MN: >=20 >> - reject, >> - re-evaluate and reject >> - re-evaluate and accept >> - accept >=20 > =3D> First, by assuming that the MN can reject the "hint" as you call = it=20 > you invalidate the whole argument for the HA to install rules.=20 > Rejecting a hint or even evaluating it means that the MN knows more.=20 > Therefore, the HA's hint is a complete waste of bandwidth. >=20 > I'm still confused about the _benefits_ you see here. Or are you=20 > assuming that the MN can't know those hints without the HA's=20 > involvement? But if you're assuming that, then how can it reject the=20 > hints? This whole proposal makes no sense to me at all. Not to mention = > the complexity you implicitly assume in order to generate those, = hopefully reliable, hints. >=20 > Hesham >=20 >=20 > On 3/06/09 5:23 PM, "Yuri Ismailov" = wrote: >=20 >> Hesham, >>=20 >> In my view these are events not scenarious. These events are known by = >> HA but not MN. If HA acts upon events, given that it knows somewhat=20 >> more about MN, not only IP addresses, it (HA) can generate new rules=20 >> and send them as hint to MN. Back again, MN has four options: >>=20 >> The benefit will be obviously that the new rules (if accepted) may=20 >> llead to a better overall communication characteristics. >>=20 >> /yuri >>=20 >>=20 >> =3D> I'm trying to understand what you mean above. These are all=20 >> scenarios, the question is: What is the benefit for the HA to=20 >> transfer rules? The HA will not know the path between the MN and CN=20 >> more than either node does. So I don't understand what _benefits_ you = see here. >>=20 >> Hesham >>=20 >>>=20 >>> Pretty much sure that there are more examples and I encourage to=20 >>> think about those not from MN point of view but rather from the HA=20 >>> service provider. >>>=20 >>> /yuri >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Wednesday, June 03, 2009 8:41 AM >>> To: Yuri Ismailov; Nicolas Montavont;=20 >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>> flowbindings >>>=20 >>> Yuri, >>>=20 >>> It is just rules TRANSFER which is the matter of MIP. So where >>>> is the logic when saying that MN to HA rules transfer is a=20 >>>> practical engineering and HA to MN is an academic interest? >>>=20 >>> =3D> I think we've (I'm including myself) highlighted several = reasons=20 >>> for why it makes little sense to transfer rules from HA to MN. >>> Instead of rat-holing on theory Vs practice, you (or others=20 >>> advocating the other direction) need to come up with reasons for=20 >>> doing things this way. This way we can think like engineers about = tradeoffs. >>> Absent that, I don't see any point in having theory Vs practice high = >>> level discussions, which will lead nowhere. >>>=20 >>> Hesham >>>=20 >>>=20 >>>>=20 >>>> Regards >>>> Yuri >>>>=20 >>>> -----Original Message----- >>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>> To: pierrick.seite@orange-ftgroup.com >>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>>> flowbindings >>>>=20 >>>> Hi Pierrick, >>>>=20 >>>> On Jun 2, 2009, at 4:11 PM, = wrote: >>>>=20 >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> Please see inline comment. >>>>>=20 >>>>> Regards, >>>>> Pierrick >>>>>=20 >>>>>> ________________________________________ >>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la=20 >>>>>> part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 : >>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important considerations=20 >>>>>> for directionality of flowbindings >>>>>>=20 >>>>>> Hesham, >>>>>> This is nice story and makes some sense for the discssion,=20 >>>>>> however some details are ommited. In your adventure with the=20 >>>>>> helpdesk, it (the >>>>>> helpdesk) is a third party service and thus your conclusions make = >>>>>> sence. >>>>>> Think of the situation when superior of a heldesk person will=20 >>>>>> tell him/her to check access point in some room. Would it be the=20 >>>>>> same reaction? I assume not. By that I mean that if, for example, = >>>>>> I'll install home agent in my home network, I can make it know=20 >>>>>> anything I want about MN, and more intresting is that how I will=20 >>>>>> do it, does not require any standardization. >>>>>> In other words, I'm superior of my HA. >>>>>> This situation is not unthinkable, I personally believe that this = >>>>>> is much more efficient way of using HA fnctionality as opposed to = >>>>>> big service providers who will have to fight with scalability and = >>>>>> performance. >>>>>> However, one does not exclude another. >>>>>> Difference between policies and rules is a convertion step. >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> The difference between policy and rules is not only a matter of=20 >>>>> conversion. A policy, is a static, or quasi-static, set of=20 >>>>> guidance for the MN (e.g use access network X for application type = >>>>> A,...) while a rule update requires to be more dynamic. I mean:=20 >>>>> eventually a policy could be updated depending on network=20 >>>>> condition (e.g if X overloaded, use access network Y for=20 >>>>> application type A,...) but a rule reacts on local triggers (e.g.=20 >>>>> modification of the radio link >>>>> quality) with a shorter period of variation. So, IMHO, there is no = >>>>> requirement for updating policy on a short period and out-of-band=20 >>>>> mechanism can be used (e.g. IEEE 802.21 in push mode,...). >>>>=20 >>>> Fully agree! >>>> This is why I do not support the exchange of rules from the HA to = the MN. >>>> Policies may be exchanged from the HA to the MN, but MIP is=20 >>>> definitely not the protocol to transport them. >>>>=20 >>>> Nicolas >>>>=20 >>>>>=20 >>>>>=20 >>>>> My 2 cents... >>>>>=20 >>>>>>=20 >>>>>> Is there any reason to restrict where such convertion takes = place? >>>>>> True >>>>>> that a HA does not know what is going on in the access network,=20 >>>>>> on the other hand HA may know what is the network condition=20 >>>>>> between HA and correspondent node. Either of this information is=20 >>>>>> important, if not equally important. >>>>>> It is not really difficult to let an MN to reject rules sent by=20 >>>>>> HA, which in my view would be quite natural. This implies that HA = >>>>>> must follow the rules installed by MN until explicit acceptance=20 >>>>>> has been received from MN. >>>>>> Such procedure is very similar to an MN beahviour when initiating = >>>>>> new BU, where MN is not supposed to send any traffic before BU=20 >>>>>> confirmation. >>>>>> BTW, what is the numerical representation of "rough consensus"? I = >>>>>> assume is when majority is for, is it so? >>>>>> Yuri >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 >>>>>> Behalf Of Hesham Soliman >>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>> To: mext >>>>>> Subject: [MEXT] Important considerations for directionality of=20 >>>>>> flow bindings >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> I've always been a fan of the IETF's tradition of rough concensus = >>>>>> (as opposed to voting). To me, this implies that you need to get=20 >>>>>> your point across and get other people to see that point of view. >>>>>> As opposed to other organisations that require their members to=20 >>>>>> vote and end up with rigid political positions. >>>>>>=20 >>>>>> The chairs asked us about the directionality question of the=20 >>>>>> flows bindings. >>>>>> On the charter question, I said that the charter doesn't need to=20 >>>>>> mention how a solution should work, but rather what problem needs = >>>>>> to be solved. >>>>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>>>> transferring rules "between" the MN and HA without mentioning = directions. >>>>>>=20 >>>>>> Nevertheless, we still need to agree on identifying the=20 >>>>>> requirement for the solution. And when it comes to this, I'm=20 >>>>>> strongly against voting and I'll practice this by explaining in=20 >>>>>> this email why I think rules can not be transferred from the HA=20 >>>>>> to the MN and that the only direction that makes sense in MIP is >>>>>> MN->HA. I'll deliberately ignore arguments like "some people want >>>>>> this" or "an SDO wants this". They fall under the "meaningless = words" >>>>>> category and I'm incapable of discussing them because they come=20 >>>>>> with voting attitudes. They all need to be justified if the WG=20 >>>>>> wants to have a technical _discussion_. >>>>>>=20 >>>>>> Here are my reasons: >>>>>>=20 >>>>>> 1. The HA does not know whether a CoA is tied to a certain access = >>>>>> technology. It is one thing for the HA to send a message saying=20 >>>>>> "forward port 80 traffic on a wifi link" (a policy) and a=20 >>>>>> completely different thing to say "forward port 80 traffic using=20 >>>>>> CoA 3ffe::1" >>>>>> (a rule). >>>>>>=20 >>>>>> 2. You might argue that the HA can be told by the MN that 3ffe::1 = >>>>>> is tied to a wifi access, so what's the problem now? The problem=20 >>>>>> is that the HA has no idea about dynamic changes on that wifi=20 >>>>>> link. It doesn't know if it's congested, it doesn't know what=20 >>>>>> application is using port 80 (it doesn't have to be web traffic)=20 >>>>>> or port 8000 for that matter and doesn't even know if the AP of=20 >>>>>> that wifi link works at all. >>>>>> Finally, it >>>>>> doesn't know the user's policies or other admin policies for that = MN. >>>>>> This type of information needs to be sent regularly because it=20 >>>>>> changes all the time and requires serious cross layer integration = >>>>>> including sometimes layer 8 integration! It's completely = impractical. >>>>>>=20 >>>>>> 3. If the HA installed rules in the MN, what happens if the MN=20 >>>>>> wants to change those rules. Say the wifi link went down, or the=20 >>>>>> MN's wifi interface went down and it wants to move that traffic=20 >>>>>> to another interface. Would the HA reject such move? Does the MN=20 >>>>>> have to justify to the HA why it needs to move traffic? Does that = >>>>>> involve writing a letter perhaps? >>>>>> If you say "well in that case, the HA should let the MN move the=20 >>>>>> traffic" >>>>>> then I'll ask you: what's the point of having the HA install this = >>>>>> stuff if it has no authority and how does it know the reason for=20 >>>>>> the MN's movement of the flow? >>>>>> The way to control how users do things is to incentivise them=20 >>>>>> with charging models and show them that things work better on=20 >>>>>> certain technologies, not by installing rules that can't be=20 >>>>>> followed. It's a broken mindset and we've known that it's broken = for a long time. >>>>>>=20 >>>>>> 4. Some people mentioned that the HA should be able to revoke=20 >>>>>> flows on the MN. I'm perfectly fine with that, just extend the=20 >>>>>> binding revocation draft to handle flows and the rest is pretty=20 >>>>>> straight forward. >>>>>>=20 >>>>>> Finally, I'll indulge in a true story that happened to me a few=20 >>>>>> years ago when I found that my wifi link wasn't working in a=20 >>>>>> hotel (no >>>>>> radio) >>>>>> and called the help desk. He insisted that the link was up an I=20 >>>>>> insisted that it wasn't. When I asked him to tell me how he knows = >>>>>> the link is up he said: I can ping the AP! Of course after=20 >>>>>> another >>>>>> 5 minutes of trying to convince him that pinging the AP doesn't=20 >>>>>> mean the radio is actually working he sent someone to the hotel=20 >>>>>> who in turn realised that the radio was not working. >>>>>> For those people who want rules to be transferred from the HA to=20 >>>>>> the MN, please think of your HA as this help desk person, i.e. it = >>>>>> has no clue about what's happening at the other end. >>>>>>=20 >>>>>> I hope this helps with the realisation that decisions can't be=20 >>>>>> made here based on voting and that there is little merit to=20 >>>>>> transferring rules from the HA to the MN. Policies can be=20 >>>>>> transferred without any problems, but not rules. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From hesham@elevatemobile.com Wed Jun 3 04:15:23 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E3773A6C78 for ; Wed, 3 Jun 2009 04:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 zjGhWMjHDNeD for ; Wed, 3 Jun 2009 04:15:21 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id C38743A6A94 for ; Wed, 3 Jun 2009 04:15:19 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MBoR2-0005VN-Ub; Wed, 03 Jun 2009 21:15:11 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Wed, 03 Jun 2009 21:15:01 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6M In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 11:15:23 -0000 >=20 > Still some answers, despite knowing that in your opinion they are not > benefits. >=20 > First of all MIP will not be breaked if the rules will be sent in both > directions. =3D> Well, that's debatable, but this is clearly not a reason to do anything. >=20 > - Access provider preferences relate to the use of backbone provider, whi= ch > may vary with the time of day. Changing backbone provider can make quite = big > difference for commnication between HA (if HA service is provided by the = same > access provider) and CN(s). The difference can be expressed in, let's say= , > number of hops, load, possibly something else. Such change is an event an= d may > have an impact on the overall communication. This can be told directly to= MN > or HA. Direct communication to MN (if accepted as benefit:-)) in such cas= e > will need standardization. Communication of this information to HA does n= ot (I > consider this as a benefit). HA may act upon that event, and the rest you > know: rules in reverse direction. =3D> There is no need to _tell_ the MN anything. There are two issues here. First, changing network conditions are best known e2e. So the MN will know that anyway based on the traffic running between it and the CN. The other issue is related to cost for certain times of day. This is a routing issue in the HA and has nothing to do with which interface the MN selects. The selected CoA has zero impact on the HA's upstream selection. Completely irrelevant actually. Of course, as far as cost on the visited link, the MN knows best. >=20 > - Access provider may set up different parameters for traffic shaping for= each > of HA interfaces. These preferences may vary independently of change of > backbone provider but dependently on the time of day. The rest you know, > whether it changes somebodies opinion. =3D> But again, this has zero effect on CoA selection. The two issues are completely orthogonal. Selecting CoA1 or CoA2 has zero impact on the HA's upstream route. >=20 > - I presume that in RO mode this is similar to HA mode, and I'm in when i= t > comes to send rules in reverse direction between CN and MN. Benefits of d= oing > that is that any change percieved by CN as important to react upon can be > expressed in proposal of new rules. The sources causing changes may inclu= de > but not limited to, are user, network managemnt events, application gener= ated > events, etc. >=20 > So feel free to consider this as benefits or not =3D> You seem to think that there is a relationship between upstream routing and CoA selection. That's not the case at all. These are two different addresses from two different networks. Hesham >=20 > /yuri >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Wednesday, June 03, 2009 11:47 AM > To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of > flowbindings >=20 >=20 >=20 >=20 > On 3/06/09 7:33 PM, "Yuri Ismailov" wrote: >=20 >> Hesham, >>=20 >> Whenever we talk about sending additional information, the "waste of >> bandwidth" can be brought up. So I do not have an answer for that >> besides speculations around it. >=20 > =3D> no no, I don't mean it literally, I mean that the message doesn't do > anything, i.e. Has no benefit. >=20 >>=20 >> Speaking about benefits, everybody who knows the area is capable of >> turning things up side down. I assume it is subjective standpoint of >> considering things as benefits or disadvantages and all is about to agre= e or >> disagree. >=20 > =3D> That's fine, I'm asking for benefits in your opinion not someone else'= s. > It's impossible to discuss this if I can't see any benefits because you d= idn't > send any. What you sent were actions that can be done by the HA and I > responded by saying that the same (or more) information is available to t= he > MN. Therefore, if you think there are additional benefits to doing this i= n the > HA then you need to tell us. >=20 > The bottom line is this: MIP works by letting the MN install bindings in = the > HA. If you want things to work in reverse you need to justify it. I can't= see > any justifications because you're not answering my questions on your > scenarios. So, count me out on the reverse direction :). >=20 >=20 > For=20 >> me those I wrote about are benefits or potential benefits if you want. >=20 > =3D> No you didn't. You wrote about things that can be done. Many things ca= n be > done by many entities, the question is why the HA and not the MN. >=20 >> One important thing in the discussion, although mentioned, but >> forgotten later is that by making rules distribution one way only, we >> do create limitation for benefits, or potential benefits if this sounds >> better. >=20 > =3D> Well, we won't know what we're missing unless someone tells us. So far= no > one has mentioned the advantages of doing things in the reverse direction= . > There is always something missing from a protocol (it's engineering), the > question us whether it's significant or worth the trouble. >=20 > Hesham >=20 >>=20 >> /yuri >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Wednesday, June 03, 2009 10:10 AM >> To: Yuri Ismailov; Nicolas Montavont; >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of >> flowbindings >>=20 >> Yuri, >>=20 >> I can't parse those events you refer to. I'l answer both emails here. >> First the events you refer to: >>=20 >>>> - network condition towards CN(s) >>>> - the sum of number of hops between MN -> HA and HA -> CN >>=20 >> =3D> What's the event? A change in those conditions? The MN knows the >> conditions of the e2e path as well as or better than the HA. What is >> the benefit of having the HA send a hint and how reliable is that hint >> anyway? >>=20 >>>> - Access provider (any access, not necessarily wireless) who offeres >>>> HA services preferences change >>=20 >> =3D> Preferences change to what?? How does it know if such change works >> for the MN at all? This is way too vague to be able to discuss tradeoffs= . >>=20 >>>> - Change of the access provider traffic to another backbone provider >>>> due to the time of the day. >>>> - Traffic condition on HA interface, which accepts traffic from MN >>>> if MN sends on some particular local interface >>=20 >> =3D> These are path changes. The HA has _no idea_ how such a change >> affects each MN/CN combination and it's "hint" can cause more problems >> than it solves. BTW, if you're talking about hints then we're no >> longer talking about installing bindings in the MN. This is a >> different topic. MIP doesn't transfer hints, it pretty much sends "order= s" >> from one end to another. >>=20 >> Now to the actions required by the MN: >>=20 >>> - reject, >>> - re-evaluate and reject >>> - re-evaluate and accept >>> - accept >>=20 >> =3D> First, by assuming that the MN can reject the "hint" as you call it >> you invalidate the whole argument for the HA to install rules. >> Rejecting a hint or even evaluating it means that the MN knows more. >> Therefore, the HA's hint is a complete waste of bandwidth. >>=20 >> I'm still confused about the _benefits_ you see here. Or are you >> assuming that the MN can't know those hints without the HA's >> involvement? But if you're assuming that, then how can it reject the >> hints? This whole proposal makes no sense to me at all. Not to mention >> the complexity you implicitly assume in order to generate those, hopeful= ly >> reliable, hints. >>=20 >> Hesham >>=20 >>=20 >> On 3/06/09 5:23 PM, "Yuri Ismailov" wrote: >>=20 >>> Hesham, >>>=20 >>> In my view these are events not scenarious. These events are known by >>> HA but not MN. If HA acts upon events, given that it knows somewhat >>> more about MN, not only IP addresses, it (HA) can generate new rules >>> and send them as hint to MN. Back again, MN has four options: >>>=20 >>> The benefit will be obviously that the new rules (if accepted) may >>> llead to a better overall communication characteristics. >>>=20 >>> /yuri >>>=20 >>>=20 >>> =3D> I'm trying to understand what you mean above. These are all >>> scenarios, the question is: What is the benefit for the HA to >>> transfer rules? The HA will not know the path between the MN and CN >>> more than either node does. So I don't understand what _benefits_ you s= ee >>> here. >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> Pretty much sure that there are more examples and I encourage to >>>> think about those not from MN point of view but rather from the HA >>>> service provider. >>>>=20 >>>> /yuri >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>> To: Yuri Ismailov; Nicolas Montavont; >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of >>>> flowbindings >>>>=20 >>>> Yuri, >>>>=20 >>>> It is just rules TRANSFER which is the matter of MIP. So where >>>>> is the logic when saying that MN to HA rules transfer is a >>>>> practical engineering and HA to MN is an academic interest? >>>>=20 >>>> =3D> I think we've (I'm including myself) highlighted several reasons >>>> for why it makes little sense to transfer rules from HA to MN. >>>> Instead of rat-holing on theory Vs practice, you (or others >>>> advocating the other direction) need to come up with reasons for >>>> doing things this way. This way we can think like engineers about >>>> tradeoffs. >>>> Absent that, I don't see any point in having theory Vs practice high >>>> level discussions, which will lead nowhere. >>>>=20 >>>> Hesham >>>>=20 >>>>=20 >>>>>=20 >>>>> Regards >>>>> Yuri >>>>>=20 >>>>> -----Original Message----- >>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>> To: pierrick.seite@orange-ftgroup.com >>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of >>>>> flowbindings >>>>>=20 >>>>> Hi Pierrick, >>>>>=20 >>>>> On Jun 2, 2009, at 4:11 PM, wrote= : >>>>>=20 >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> Please see inline comment. >>>>>>=20 >>>>>> Regards, >>>>>> Pierrick >>>>>>=20 >>>>>>> ________________________________________ >>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la >>>>>>> part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 : >>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important considerations >>>>>>> for directionality of flowbindings >>>>>>>=20 >>>>>>> Hesham, >>>>>>> This is nice story and makes some sense for the discssion, >>>>>>> however some details are ommited. In your adventure with the >>>>>>> helpdesk, it (the >>>>>>> helpdesk) is a third party service and thus your conclusions make >>>>>>> sence. >>>>>>> Think of the situation when superior of a heldesk person will >>>>>>> tell him/her to check access point in some room. Would it be the >>>>>>> same reaction? I assume not. By that I mean that if, for example, >>>>>>> I'll install home agent in my home network, I can make it know >>>>>>> anything I want about MN, and more intresting is that how I will >>>>>>> do it, does not require any standardization. >>>>>>> In other words, I'm superior of my HA. >>>>>>> This situation is not unthinkable, I personally believe that this >>>>>>> is much more efficient way of using HA fnctionality as opposed to >>>>>>> big service providers who will have to fight with scalability and >>>>>>> performance. >>>>>>> However, one does not exclude another. >>>>>>> Difference between policies and rules is a convertion step. >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The difference between policy and rules is not only a matter of >>>>>> conversion. A policy, is a static, or quasi-static, set of >>>>>> guidance for the MN (e.g use access network X for application type >>>>>> A,...) while a rule update requires to be more dynamic. I mean: >>>>>> eventually a policy could be updated depending on network >>>>>> condition (e.g if X overloaded, use access network Y for >>>>>> application type A,...) but a rule reacts on local triggers (e.g. >>>>>> modification of the radio link >>>>>> quality) with a shorter period of variation. So, IMHO, there is no >>>>>> requirement for updating policy on a short period and out-of-band >>>>>> mechanism can be used (e.g. IEEE 802.21 in push mode,...). >>>>>=20 >>>>> Fully agree! >>>>> This is why I do not support the exchange of rules from the HA to the= MN. >>>>> Policies may be exchanged from the HA to the MN, but MIP is >>>>> definitely not the protocol to transport them. >>>>>=20 >>>>> Nicolas >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> My 2 cents... >>>>>>=20 >>>>>>>=20 >>>>>>> Is there any reason to restrict where such convertion takes place? >>>>>>> True >>>>>>> that a HA does not know what is going on in the access network, >>>>>>> on the other hand HA may know what is the network condition >>>>>>> between HA and correspondent node. Either of this information is >>>>>>> important, if not equally important. >>>>>>> It is not really difficult to let an MN to reject rules sent by >>>>>>> HA, which in my view would be quite natural. This implies that HA >>>>>>> must follow the rules installed by MN until explicit acceptance >>>>>>> has been received from MN. >>>>>>> Such procedure is very similar to an MN beahviour when initiating >>>>>>> new BU, where MN is not supposed to send any traffic before BU >>>>>>> confirmation. >>>>>>> BTW, what is the numerical representation of "rough consensus"? I >>>>>>> assume is when majority is for, is it so? >>>>>>> Yuri >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>>>>> Behalf Of Hesham Soliman >>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>> To: mext >>>>>>> Subject: [MEXT] Important considerations for directionality of >>>>>>> flow bindings >>>>>>>=20 >>>>>>> Hi all, >>>>>>>=20 >>>>>>> I've always been a fan of the IETF's tradition of rough concensus >>>>>>> (as opposed to voting). To me, this implies that you need to get >>>>>>> your point across and get other people to see that point of view. >>>>>>> As opposed to other organisations that require their members to >>>>>>> vote and end up with rigid political positions. >>>>>>>=20 >>>>>>> The chairs asked us about the directionality question of the >>>>>>> flows bindings. >>>>>>> On the charter question, I said that the charter doesn't need to >>>>>>> mention how a solution should work, but rather what problem needs >>>>>>> to be solved. >>>>>>> Hence, as far as the charter is concerned, I'm fine with >>>>>>> transferring rules "between" the MN and HA without mentioning >>>>>>> directions. >>>>>>>=20 >>>>>>> Nevertheless, we still need to agree on identifying the >>>>>>> requirement for the solution. And when it comes to this, I'm >>>>>>> strongly against voting and I'll practice this by explaining in >>>>>>> this email why I think rules can not be transferred from the HA >>>>>>> to the MN and that the only direction that makes sense in MIP is >>>>>>> MN->HA. I'll deliberately ignore arguments like "some people want >>>>>>> this" or "an SDO wants this". They fall under the "meaningless word= s" >>>>>>> category and I'm incapable of discussing them because they come >>>>>>> with voting attitudes. They all need to be justified if the WG >>>>>>> wants to have a technical _discussion_. >>>>>>>=20 >>>>>>> Here are my reasons: >>>>>>>=20 >>>>>>> 1. The HA does not know whether a CoA is tied to a certain access >>>>>>> technology. It is one thing for the HA to send a message saying >>>>>>> "forward port 80 traffic on a wifi link" (a policy) and a >>>>>>> completely different thing to say "forward port 80 traffic using >>>>>>> CoA 3ffe::1" >>>>>>> (a rule). >>>>>>>=20 >>>>>>> 2. You might argue that the HA can be told by the MN that 3ffe::1 >>>>>>> is tied to a wifi access, so what's the problem now? The problem >>>>>>> is that the HA has no idea about dynamic changes on that wifi >>>>>>> link. It doesn't know if it's congested, it doesn't know what >>>>>>> application is using port 80 (it doesn't have to be web traffic) >>>>>>> or port 8000 for that matter and doesn't even know if the AP of >>>>>>> that wifi link works at all. >>>>>>> Finally, it >>>>>>> doesn't know the user's policies or other admin policies for that M= N. >>>>>>> This type of information needs to be sent regularly because it >>>>>>> changes all the time and requires serious cross layer integration >>>>>>> including sometimes layer 8 integration! It's completely impractica= l. >>>>>>>=20 >>>>>>> 3. If the HA installed rules in the MN, what happens if the MN >>>>>>> wants to change those rules. Say the wifi link went down, or the >>>>>>> MN's wifi interface went down and it wants to move that traffic >>>>>>> to another interface. Would the HA reject such move? Does the MN >>>>>>> have to justify to the HA why it needs to move traffic? Does that >>>>>>> involve writing a letter perhaps? >>>>>>> If you say "well in that case, the HA should let the MN move the >>>>>>> traffic" >>>>>>> then I'll ask you: what's the point of having the HA install this >>>>>>> stuff if it has no authority and how does it know the reason for >>>>>>> the MN's movement of the flow? >>>>>>> The way to control how users do things is to incentivise them >>>>>>> with charging models and show them that things work better on >>>>>>> certain technologies, not by installing rules that can't be >>>>>>> followed. It's a broken mindset and we've known that it's broken fo= r a >>>>>>> long time. >>>>>>>=20 >>>>>>> 4. Some people mentioned that the HA should be able to revoke >>>>>>> flows on the MN. I'm perfectly fine with that, just extend the >>>>>>> binding revocation draft to handle flows and the rest is pretty >>>>>>> straight forward. >>>>>>>=20 >>>>>>> Finally, I'll indulge in a true story that happened to me a few >>>>>>> years ago when I found that my wifi link wasn't working in a >>>>>>> hotel (no >>>>>>> radio) >>>>>>> and called the help desk. He insisted that the link was up an I >>>>>>> insisted that it wasn't. When I asked him to tell me how he knows >>>>>>> the link is up he said: I can ping the AP! Of course after >>>>>>> another >>>>>>> 5 minutes of trying to convince him that pinging the AP doesn't >>>>>>> mean the radio is actually working he sent someone to the hotel >>>>>>> who in turn realised that the radio was not working. >>>>>>> For those people who want rules to be transferred from the HA to >>>>>>> the MN, please think of your HA as this help desk person, i.e. it >>>>>>> has no clue about what's happening at the other end. >>>>>>>=20 >>>>>>> I hope this helps with the realisation that decisions can't be >>>>>>> made here based on voting and that there is little merit to >>>>>>> transferring rules from the HA to the MN. Policies can be >>>>>>> transferred without any problems, but not rules. >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From yuri.ismailov@ericsson.com Wed Jun 3 07:00:56 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454103A68DD for ; Wed, 3 Jun 2009 07:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.027 X-Spam-Level: X-Spam-Status: No, score=-8.027 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 GzWHx2g0vtsp for ; Wed, 3 Jun 2009 07:00:51 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 295E23A6B49 for ; Wed, 3 Jun 2009 07:00:49 -0700 (PDT) X-AuditID: c1b4fb3c-b7b14ae0000039d7-b6-4a268201f94c Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 8C.42.14807.102862A4; Wed, 3 Jun 2009 16:00:33 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jun 2009 14:47:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 14:47:13 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NA= References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 03 Jun 2009 12:47:26.0969 (UTC) FILETIME=[72FCDE90:01C9E449] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 14:00:56 -0000 Ok, see your point, however:-) The major difference here is that your are talking about CoA selection = and I'm talking about interface selection. Quite a big difference. I do not see any grounds for MN to select CoA, based on what? Prefix = length? While selection of an interface is based on expected = characteristics of the communication. Routes (up/down)link in my opinion = do have impact on the characteristics and this is exactly the = information missing in the MN when selecting interface. Whenever, MN decides to move a flow, the reason can be anything but not = which CoA it has configured on each interface. Another thing is that MN will notice something e2e if and only if such = support is implemented in the MN. Moreover, this notice can not be made = at IP layer. TCP fights alone with all problems and never tells to any = other layer what is going on. So what is left? Two options. Add this = support to operating system, which makes its (support) existence = questionable, or to applications, which is even more questionable. >> >> Well, that's debatable, but this is clearly not a reason to do = anything. >> Are you serious about that MIP may be broken because of that? /yuri -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Wednesday, June 03, 2009 1:15 PM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings >=20 > Still some answers, despite knowing that in your opinion they are not=20 > benefits. >=20 > First of all MIP will not be breaked if the rules will be sent in both = > directions. =3D> Well, that's debatable, but this is clearly not a reason to do = anything. >=20 > - Access provider preferences relate to the use of backbone provider,=20 > which may vary with the time of day. Changing backbone provider can=20 > make quite big difference for commnication between HA (if HA service=20 > is provided by the same access provider) and CN(s). The difference can = > be expressed in, let's say, number of hops, load, possibly something=20 > else. Such change is an event and may have an impact on the overall=20 > communication. This can be told directly to MN or HA. Direct=20 > communication to MN (if accepted as benefit:-)) in such case will need = > standardization. Communication of this information to HA does not (I=20 > consider this as a benefit). HA may act upon that event, and the rest=20 > you > know: rules in reverse direction. =3D> There is no need to _tell_ the MN anything. There are two issues = here. First, changing network conditions are best known e2e. So the MN will = know that anyway based on the traffic running between it and the CN. The = other issue is related to cost for certain times of day. This is a = routing issue in the HA and has nothing to do with which interface the = MN selects. The selected CoA has zero impact on the HA's upstream = selection. Completely irrelevant actually. Of course, as far as cost on the visited link, the MN knows best. >=20 > - Access provider may set up different parameters for traffic shaping=20 > for each of HA interfaces. These preferences may vary independently of = > change of backbone provider but dependently on the time of day. The=20 > rest you know, whether it changes somebodies opinion. =3D> But again, this has zero effect on CoA selection. The two issues = are completely orthogonal. Selecting CoA1 or CoA2 has zero impact on the = HA's upstream route. >=20 > - I presume that in RO mode this is similar to HA mode, and I'm in=20 > when it comes to send rules in reverse direction between CN and MN.=20 > Benefits of doing that is that any change percieved by CN as important = > to react upon can be expressed in proposal of new rules. The sources=20 > causing changes may include but not limited to, are user, network=20 > managemnt events, application generated events, etc. >=20 > So feel free to consider this as benefits or not =3D> You seem to think that there is a relationship between upstream = routing and CoA selection. That's not the case at all. These are two = different addresses from two different networks. Hesham >=20 > /yuri >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Wednesday, June 03, 2009 11:47 AM > To: Yuri Ismailov; Nicolas Montavont;=20 > pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of=20 > flowbindings >=20 >=20 >=20 >=20 > On 3/06/09 7:33 PM, "Yuri Ismailov" = wrote: >=20 >> Hesham, >>=20 >> Whenever we talk about sending additional information, the "waste of=20 >> bandwidth" can be brought up. So I do not have an answer for that=20 >> besides speculations around it. >=20 > =3D> no no, I don't mean it literally, I mean that the message doesn't = > do anything, i.e. Has no benefit. >=20 >>=20 >> Speaking about benefits, everybody who knows the area is capable of=20 >> turning things up side down. I assume it is subjective standpoint of=20 >> considering things as benefits or disadvantages and all is about to=20 >> agree or disagree. >=20 > =3D> That's fine, I'm asking for benefits in your opinion not someone = else's. > It's impossible to discuss this if I can't see any benefits because=20 > you didn't send any. What you sent were actions that can be done by=20 > the HA and I responded by saying that the same (or more) information=20 > is available to the MN. Therefore, if you think there are additional=20 > benefits to doing this in the HA then you need to tell us. >=20 > The bottom line is this: MIP works by letting the MN install bindings=20 > in the HA. If you want things to work in reverse you need to justify=20 > it. I can't see any justifications because you're not answering my=20 > questions on your scenarios. So, count me out on the reverse direction = :). >=20 >=20 > For >> me those I wrote about are benefits or potential benefits if you = want. >=20 > =3D> No you didn't. You wrote about things that can be done. Many = things=20 > can be done by many entities, the question is why the HA and not the = MN. >=20 >> One important thing in the discussion, although mentioned, but=20 >> forgotten later is that by making rules distribution one way only, we = >> do create limitation for benefits, or potential benefits if this=20 >> sounds better. >=20 > =3D> Well, we won't know what we're missing unless someone tells us. = So=20 > far no one has mentioned the advantages of doing things in the reverse = direction. > There is always something missing from a protocol (it's engineering),=20 > the question us whether it's significant or worth the trouble. >=20 > Hesham >=20 >>=20 >> /yuri >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Wednesday, June 03, 2009 10:10 AM >> To: Yuri Ismailov; Nicolas Montavont;=20 >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of=20 >> flowbindings >>=20 >> Yuri, >>=20 >> I can't parse those events you refer to. I'l answer both emails here. >> First the events you refer to: >>=20 >>>> - network condition towards CN(s) >>>> - the sum of number of hops between MN -> HA and HA -> CN >>=20 >> =3D> What's the event? A change in those conditions? The MN knows the = >> conditions of the e2e path as well as or better than the HA. What is=20 >> the benefit of having the HA send a hint and how reliable is that=20 >> hint anyway? >>=20 >>>> - Access provider (any access, not necessarily wireless) who=20 >>>> offeres HA services preferences change >>=20 >> =3D> Preferences change to what?? How does it know if such change = works=20 >> for the MN at all? This is way too vague to be able to discuss = tradeoffs. >>=20 >>>> - Change of the access provider traffic to another backbone=20 >>>> provider due to the time of the day. >>>> - Traffic condition on HA interface, which accepts traffic from MN=20 >>>> if MN sends on some particular local interface >>=20 >> =3D> These are path changes. The HA has _no idea_ how such a change=20 >> affects each MN/CN combination and it's "hint" can cause more=20 >> problems than it solves. BTW, if you're talking about hints then=20 >> we're no longer talking about installing bindings in the MN. This is=20 >> a different topic. MIP doesn't transfer hints, it pretty much sends = "orders" >> from one end to another. >>=20 >> Now to the actions required by the MN: >>=20 >>> - reject, >>> - re-evaluate and reject >>> - re-evaluate and accept >>> - accept >>=20 >> =3D> First, by assuming that the MN can reject the "hint" as you call = >> it you invalidate the whole argument for the HA to install rules. >> Rejecting a hint or even evaluating it means that the MN knows more. >> Therefore, the HA's hint is a complete waste of bandwidth. >>=20 >> I'm still confused about the _benefits_ you see here. Or are you=20 >> assuming that the MN can't know those hints without the HA's=20 >> involvement? But if you're assuming that, then how can it reject the=20 >> hints? This whole proposal makes no sense to me at all. Not to=20 >> mention the complexity you implicitly assume in order to generate=20 >> those, hopefully reliable, hints. >>=20 >> Hesham >>=20 >>=20 >> On 3/06/09 5:23 PM, "Yuri Ismailov" = wrote: >>=20 >>> Hesham, >>>=20 >>> In my view these are events not scenarious. These events are known=20 >>> by HA but not MN. If HA acts upon events, given that it knows=20 >>> somewhat more about MN, not only IP addresses, it (HA) can generate=20 >>> new rules and send them as hint to MN. Back again, MN has four = options: >>>=20 >>> The benefit will be obviously that the new rules (if accepted) may=20 >>> llead to a better overall communication characteristics. >>>=20 >>> /yuri >>>=20 >>>=20 >>> =3D> I'm trying to understand what you mean above. These are all=20 >>> scenarios, the question is: What is the benefit for the HA to=20 >>> transfer rules? The HA will not know the path between the MN and CN=20 >>> more than either node does. So I don't understand what _benefits_=20 >>> you see here. >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> Pretty much sure that there are more examples and I encourage to=20 >>>> think about those not from MN point of view but rather from the HA=20 >>>> service provider. >>>>=20 >>>> /yuri >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>>> flowbindings >>>>=20 >>>> Yuri, >>>>=20 >>>> It is just rules TRANSFER which is the matter of MIP. So where >>>>> is the logic when saying that MN to HA rules transfer is a=20 >>>>> practical engineering and HA to MN is an academic interest? >>>>=20 >>>> =3D> I think we've (I'm including myself) highlighted several = reasons=20 >>>> for why it makes little sense to transfer rules from HA to MN. >>>> Instead of rat-holing on theory Vs practice, you (or others=20 >>>> advocating the other direction) need to come up with reasons for=20 >>>> doing things this way. This way we can think like engineers about=20 >>>> tradeoffs. >>>> Absent that, I don't see any point in having theory Vs practice=20 >>>> high level discussions, which will lead nowhere. >>>>=20 >>>> Hesham >>>>=20 >>>>=20 >>>>>=20 >>>>> Regards >>>>> Yuri >>>>>=20 >>>>> -----Original Message----- >>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>> To: pierrick.seite@orange-ftgroup.com >>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of = >>>>> flowbindings >>>>>=20 >>>>> Hi Pierrick, >>>>>=20 >>>>> On Jun 2, 2009, at 4:11 PM, = wrote: >>>>>=20 >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> Please see inline comment. >>>>>>=20 >>>>>> Regards, >>>>>> Pierrick >>>>>>=20 >>>>>>> ________________________________________ >>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la=20 >>>>>>> part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 = : >>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important considerations = >>>>>>> for directionality of flowbindings >>>>>>>=20 >>>>>>> Hesham, >>>>>>> This is nice story and makes some sense for the discssion,=20 >>>>>>> however some details are ommited. In your adventure with the=20 >>>>>>> helpdesk, it (the >>>>>>> helpdesk) is a third party service and thus your conclusions=20 >>>>>>> make sence. >>>>>>> Think of the situation when superior of a heldesk person will=20 >>>>>>> tell him/her to check access point in some room. Would it be the = >>>>>>> same reaction? I assume not. By that I mean that if, for=20 >>>>>>> example, I'll install home agent in my home network, I can make=20 >>>>>>> it know anything I want about MN, and more intresting is that=20 >>>>>>> how I will do it, does not require any standardization. >>>>>>> In other words, I'm superior of my HA. >>>>>>> This situation is not unthinkable, I personally believe that=20 >>>>>>> this is much more efficient way of using HA fnctionality as=20 >>>>>>> opposed to big service providers who will have to fight with=20 >>>>>>> scalability and performance. >>>>>>> However, one does not exclude another. >>>>>>> Difference between policies and rules is a convertion step. >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The difference between policy and rules is not only a matter of=20 >>>>>> conversion. A policy, is a static, or quasi-static, set of=20 >>>>>> guidance for the MN (e.g use access network X for application=20 >>>>>> type >>>>>> A,...) while a rule update requires to be more dynamic. I mean: >>>>>> eventually a policy could be updated depending on network=20 >>>>>> condition (e.g if X overloaded, use access network Y for=20 >>>>>> application type A,...) but a rule reacts on local triggers (e.g. >>>>>> modification of the radio link >>>>>> quality) with a shorter period of variation. So, IMHO, there is=20 >>>>>> no requirement for updating policy on a short period and=20 >>>>>> out-of-band mechanism can be used (e.g. IEEE 802.21 in push = mode,...). >>>>>=20 >>>>> Fully agree! >>>>> This is why I do not support the exchange of rules from the HA to = the MN. >>>>> Policies may be exchanged from the HA to the MN, but MIP is=20 >>>>> definitely not the protocol to transport them. >>>>>=20 >>>>> Nicolas >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> My 2 cents... >>>>>>=20 >>>>>>>=20 >>>>>>> Is there any reason to restrict where such convertion takes = place? >>>>>>> True >>>>>>> that a HA does not know what is going on in the access network,=20 >>>>>>> on the other hand HA may know what is the network condition=20 >>>>>>> between HA and correspondent node. Either of this information is = >>>>>>> important, if not equally important. >>>>>>> It is not really difficult to let an MN to reject rules sent by=20 >>>>>>> HA, which in my view would be quite natural. This implies that=20 >>>>>>> HA must follow the rules installed by MN until explicit=20 >>>>>>> acceptance has been received from MN. >>>>>>> Such procedure is very similar to an MN beahviour when=20 >>>>>>> initiating new BU, where MN is not supposed to send any traffic=20 >>>>>>> before BU confirmation. >>>>>>> BTW, what is the numerical representation of "rough consensus"?=20 >>>>>>> I assume is when majority is for, is it so? >>>>>>> Yuri >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 >>>>>>> Behalf Of Hesham Soliman >>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>> To: mext >>>>>>> Subject: [MEXT] Important considerations for directionality of=20 >>>>>>> flow bindings >>>>>>>=20 >>>>>>> Hi all, >>>>>>>=20 >>>>>>> I've always been a fan of the IETF's tradition of rough=20 >>>>>>> concensus (as opposed to voting). To me, this implies that you=20 >>>>>>> need to get your point across and get other people to see that = point of view. >>>>>>> As opposed to other organisations that require their members to=20 >>>>>>> vote and end up with rigid political positions. >>>>>>>=20 >>>>>>> The chairs asked us about the directionality question of the=20 >>>>>>> flows bindings. >>>>>>> On the charter question, I said that the charter doesn't need to = >>>>>>> mention how a solution should work, but rather what problem=20 >>>>>>> needs to be solved. >>>>>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>>>>> transferring rules "between" the MN and HA without mentioning=20 >>>>>>> directions. >>>>>>>=20 >>>>>>> Nevertheless, we still need to agree on identifying the=20 >>>>>>> requirement for the solution. And when it comes to this, I'm=20 >>>>>>> strongly against voting and I'll practice this by explaining in=20 >>>>>>> this email why I think rules can not be transferred from the HA=20 >>>>>>> to the MN and that the only direction that makes sense in MIP is >>>>>>> MN->HA. I'll deliberately ignore arguments like "some people=20 >>>>>>> MN->want >>>>>>> this" or "an SDO wants this". They fall under the "meaningless = words" >>>>>>> category and I'm incapable of discussing them because they come=20 >>>>>>> with voting attitudes. They all need to be justified if the WG=20 >>>>>>> wants to have a technical _discussion_. >>>>>>>=20 >>>>>>> Here are my reasons: >>>>>>>=20 >>>>>>> 1. The HA does not know whether a CoA is tied to a certain=20 >>>>>>> access technology. It is one thing for the HA to send a message=20 >>>>>>> saying "forward port 80 traffic on a wifi link" (a policy) and a = >>>>>>> completely different thing to say "forward port 80 traffic using = >>>>>>> CoA 3ffe::1" >>>>>>> (a rule). >>>>>>>=20 >>>>>>> 2. You might argue that the HA can be told by the MN that=20 >>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem now? The = >>>>>>> problem is that the HA has no idea about dynamic changes on that = >>>>>>> wifi link. It doesn't know if it's congested, it doesn't know=20 >>>>>>> what application is using port 80 (it doesn't have to be web=20 >>>>>>> traffic) or port 8000 for that matter and doesn't even know if=20 >>>>>>> the AP of that wifi link works at all. >>>>>>> Finally, it >>>>>>> doesn't know the user's policies or other admin policies for = that MN. >>>>>>> This type of information needs to be sent regularly because it=20 >>>>>>> changes all the time and requires serious cross layer=20 >>>>>>> integration including sometimes layer 8 integration! It's = completely impractical. >>>>>>>=20 >>>>>>> 3. If the HA installed rules in the MN, what happens if the MN=20 >>>>>>> wants to change those rules. Say the wifi link went down, or the = >>>>>>> MN's wifi interface went down and it wants to move that traffic=20 >>>>>>> to another interface. Would the HA reject such move? Does the MN = >>>>>>> have to justify to the HA why it needs to move traffic? Does=20 >>>>>>> that involve writing a letter perhaps? >>>>>>> If you say "well in that case, the HA should let the MN move the = >>>>>>> traffic" >>>>>>> then I'll ask you: what's the point of having the HA install=20 >>>>>>> this stuff if it has no authority and how does it know the=20 >>>>>>> reason for the MN's movement of the flow? >>>>>>> The way to control how users do things is to incentivise them=20 >>>>>>> with charging models and show them that things work better on=20 >>>>>>> certain technologies, not by installing rules that can't be=20 >>>>>>> followed. It's a broken mindset and we've known that it's broken = >>>>>>> for a long time. >>>>>>>=20 >>>>>>> 4. Some people mentioned that the HA should be able to revoke=20 >>>>>>> flows on the MN. I'm perfectly fine with that, just extend the=20 >>>>>>> binding revocation draft to handle flows and the rest is pretty=20 >>>>>>> straight forward. >>>>>>>=20 >>>>>>> Finally, I'll indulge in a true story that happened to me a few=20 >>>>>>> years ago when I found that my wifi link wasn't working in a=20 >>>>>>> hotel (no >>>>>>> radio) >>>>>>> and called the help desk. He insisted that the link was up an I=20 >>>>>>> insisted that it wasn't. When I asked him to tell me how he=20 >>>>>>> knows the link is up he said: I can ping the AP! Of course after = >>>>>>> another >>>>>>> 5 minutes of trying to convince him that pinging the AP doesn't=20 >>>>>>> mean the radio is actually working he sent someone to the hotel=20 >>>>>>> who in turn realised that the radio was not working. >>>>>>> For those people who want rules to be transferred from the HA to = >>>>>>> the MN, please think of your HA as this help desk person, i.e.=20 >>>>>>> it has no clue about what's happening at the other end. >>>>>>>=20 >>>>>>> I hope this helps with the realisation that decisions can't be=20 >>>>>>> made here based on voting and that there is little merit to=20 >>>>>>> transferring rules from the HA to the MN. Policies can be=20 >>>>>>> transferred without any problems, but not rules. >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From hesham@elevatemobile.com Wed Jun 3 07:10:12 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35C193A6B7D for ; Wed, 3 Jun 2009 07:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 dMxU1FTBSzC1 for ; Wed, 3 Jun 2009 07:10:06 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id DADBD3A69E7 for ; Wed, 3 Jun 2009 07:09:18 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MBr9F-0003fF-JH; Thu, 04 Jun 2009 00:08:59 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 04 Jun 2009 00:08:50 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 14:10:12 -0000 On 3/06/09 10:47 PM, "Yuri Ismailov" wrote: > Ok, see your point, however:-) >=20 > The major difference here is that your are talking about CoA selection an= d I'm > talking about interface selection. Quite a big difference. =3D> No, that's not the point really. The point is that there is no relationship between CoA/interface selection on the MN and the upstream ISP for the home network. > I do not see any grounds for MN to select CoA, based on what? Prefix leng= th? > While selection of an interface is based on expected characteristics of t= he > communication. Routes (up/down)link in my opinion do have impact on the > characteristics and this is exactly the information missing in the MN whe= n > selecting interface. =3D> There is nothing missing for the MN to make this selection. Please tell us specifically what is missing. You're changing points on me all the time now. Lets stick to one point at a time. What's missing? >=20 > Whenever, MN decides to move a flow, the reason can be anything but not w= hich > CoA it has configured on each interface. >=20 > Another thing is that MN will notice something e2e if and only if such su= pport > is implemented in the MN. =3D> Of course, so what? Moreover, this notice can not be made at IP layer. > TCP fights alone with all problems and never tells to any other layer wha= t is > going on. So what is left? Two options. Add this support to operating sys= tem, > which makes its (support) existence questionable, or to applications, whi= ch is > even more questionable. =3D> It's interesting that you think it's questionable to add the support to the MN's OS but not questionable to add the support to the HA's OS, which will not lead to the same reliability as if it were done in the MN. It doesn't make sense to me. >=20 >>>=20 >>> Well, that's debatable, but this is clearly not a reason to do anything= . >>>=20 > Are you serious about that MIP may be broken because of that? =3D> Yes! It's not designed to do what you want to do. Luckily, in this case what you want, IMO, is broken anyway so it's not a problem. Hesham >=20 > /yuri >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Wednesday, June 03, 2009 1:15 PM > To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of > flowbindings >=20 >=20 >=20 >>=20 >> Still some answers, despite knowing that in your opinion they are not >> benefits. >>=20 >> First of all MIP will not be breaked if the rules will be sent in both >> directions. >=20 > =3D> Well, that's debatable, but this is clearly not a reason to do anythin= g. >=20 >>=20 >> - Access provider preferences relate to the use of backbone provider, >> which may vary with the time of day. Changing backbone provider can >> make quite big difference for commnication between HA (if HA service >> is provided by the same access provider) and CN(s). The difference can >> be expressed in, let's say, number of hops, load, possibly something >> else. Such change is an event and may have an impact on the overall >> communication. This can be told directly to MN or HA. Direct >> communication to MN (if accepted as benefit:-)) in such case will need >> standardization. Communication of this information to HA does not (I >> consider this as a benefit). HA may act upon that event, and the rest >> you >> know: rules in reverse direction. >=20 > =3D> There is no need to _tell_ the MN anything. There are two issues here. > First, changing network conditions are best known e2e. So the MN will kno= w > that anyway based on the traffic running between it and the CN. The other > issue is related to cost for certain times of day. This is a routing issu= e in > the HA and has nothing to do with which interface the MN selects. The sel= ected > CoA has zero impact on the HA's upstream selection. Completely irrelevant > actually. > Of course, as far as cost on the visited link, the MN knows best. >=20 >>=20 >> - Access provider may set up different parameters for traffic shaping >> for each of HA interfaces. These preferences may vary independently of >> change of backbone provider but dependently on the time of day. The >> rest you know, whether it changes somebodies opinion. >=20 > =3D> But again, this has zero effect on CoA selection. The two issues are > completely orthogonal. Selecting CoA1 or CoA2 has zero impact on the HA's > upstream route. >=20 >>=20 >> - I presume that in RO mode this is similar to HA mode, and I'm in >> when it comes to send rules in reverse direction between CN and MN. >> Benefits of doing that is that any change percieved by CN as important >> to react upon can be expressed in proposal of new rules. The sources >> causing changes may include but not limited to, are user, network >> managemnt events, application generated events, etc. >>=20 >> So feel free to consider this as benefits or not >=20 > =3D> You seem to think that there is a relationship between upstream routin= g and > CoA selection. That's not the case at all. These are two different addres= ses > from two different networks. >=20 > Hesham >=20 >>=20 >> /yuri >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Wednesday, June 03, 2009 11:47 AM >> To: Yuri Ismailov; Nicolas Montavont; >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of >> flowbindings >>=20 >>=20 >>=20 >>=20 >> On 3/06/09 7:33 PM, "Yuri Ismailov" wrote: >>=20 >>> Hesham, >>>=20 >>> Whenever we talk about sending additional information, the "waste of >>> bandwidth" can be brought up. So I do not have an answer for that >>> besides speculations around it. >>=20 >> =3D> no no, I don't mean it literally, I mean that the message doesn't >> do anything, i.e. Has no benefit. >>=20 >>>=20 >>> Speaking about benefits, everybody who knows the area is capable of >>> turning things up side down. I assume it is subjective standpoint of >>> considering things as benefits or disadvantages and all is about to >>> agree or disagree. >>=20 >> =3D> That's fine, I'm asking for benefits in your opinion not someone else= 's. >> It's impossible to discuss this if I can't see any benefits because >> you didn't send any. What you sent were actions that can be done by >> the HA and I responded by saying that the same (or more) information >> is available to the MN. Therefore, if you think there are additional >> benefits to doing this in the HA then you need to tell us. >>=20 >> The bottom line is this: MIP works by letting the MN install bindings >> in the HA. If you want things to work in reverse you need to justify >> it. I can't see any justifications because you're not answering my >> questions on your scenarios. So, count me out on the reverse direction := ). >>=20 >>=20 >> For >>> me those I wrote about are benefits or potential benefits if you want. >>=20 >> =3D> No you didn't. You wrote about things that can be done. Many things >> can be done by many entities, the question is why the HA and not the MN. >>=20 >>> One important thing in the discussion, although mentioned, but >>> forgotten later is that by making rules distribution one way only, we >>> do create limitation for benefits, or potential benefits if this >>> sounds better. >>=20 >> =3D> Well, we won't know what we're missing unless someone tells us. So >> far no one has mentioned the advantages of doing things in the reverse >> direction. >> There is always something missing from a protocol (it's engineering), >> the question us whether it's significant or worth the trouble. >>=20 >> Hesham >>=20 >>>=20 >>> /yuri >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Wednesday, June 03, 2009 10:10 AM >>> To: Yuri Ismailov; Nicolas Montavont; >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of >>> flowbindings >>>=20 >>> Yuri, >>>=20 >>> I can't parse those events you refer to. I'l answer both emails here. >>> First the events you refer to: >>>=20 >>>>> - network condition towards CN(s) >>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>=20 >>> =3D> What's the event? A change in those conditions? The MN knows the >>> conditions of the e2e path as well as or better than the HA. What is >>> the benefit of having the HA send a hint and how reliable is that >>> hint anyway? >>>=20 >>>>> - Access provider (any access, not necessarily wireless) who >>>>> offeres HA services preferences change >>>=20 >>> =3D> Preferences change to what?? How does it know if such change works >>> for the MN at all? This is way too vague to be able to discuss tradeoff= s. >>>=20 >>>>> - Change of the access provider traffic to another backbone >>>>> provider due to the time of the day. >>>>> - Traffic condition on HA interface, which accepts traffic from MN >>>>> if MN sends on some particular local interface >>>=20 >>> =3D> These are path changes. The HA has _no idea_ how such a change >>> affects each MN/CN combination and it's "hint" can cause more >>> problems than it solves. BTW, if you're talking about hints then >>> we're no longer talking about installing bindings in the MN. This is >>> a different topic. MIP doesn't transfer hints, it pretty much sends "or= ders" >>> from one end to another. >>>=20 >>> Now to the actions required by the MN: >>>=20 >>>> - reject, >>>> - re-evaluate and reject >>>> - re-evaluate and accept >>>> - accept >>>=20 >>> =3D> First, by assuming that the MN can reject the "hint" as you call >>> it you invalidate the whole argument for the HA to install rules. >>> Rejecting a hint or even evaluating it means that the MN knows more. >>> Therefore, the HA's hint is a complete waste of bandwidth. >>>=20 >>> I'm still confused about the _benefits_ you see here. Or are you >>> assuming that the MN can't know those hints without the HA's >>> involvement? But if you're assuming that, then how can it reject the >>> hints? This whole proposal makes no sense to me at all. Not to >>> mention the complexity you implicitly assume in order to generate >>> those, hopefully reliable, hints. >>>=20 >>> Hesham >>>=20 >>>=20 >>> On 3/06/09 5:23 PM, "Yuri Ismailov" wrote: >>>=20 >>>> Hesham, >>>>=20 >>>> In my view these are events not scenarious. These events are known >>>> by HA but not MN. If HA acts upon events, given that it knows >>>> somewhat more about MN, not only IP addresses, it (HA) can generate >>>> new rules and send them as hint to MN. Back again, MN has four options= : >>>>=20 >>>> The benefit will be obviously that the new rules (if accepted) may >>>> llead to a better overall communication characteristics. >>>>=20 >>>> /yuri >>>>=20 >>>>=20 >>>> =3D> I'm trying to understand what you mean above. These are all >>>> scenarios, the question is: What is the benefit for the HA to >>>> transfer rules? The HA will not know the path between the MN and CN >>>> more than either node does. So I don't understand what _benefits_ >>>> you see here. >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> Pretty much sure that there are more examples and I encourage to >>>>> think about those not from MN point of view but rather from the HA >>>>> service provider. >>>>>=20 >>>>> /yuri >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>> pierrick.seite@orange-ftgroup.com >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of >>>>> flowbindings >>>>>=20 >>>>> Yuri, >>>>>=20 >>>>> It is just rules TRANSFER which is the matter of MIP. So where >>>>>> is the logic when saying that MN to HA rules transfer is a >>>>>> practical engineering and HA to MN is an academic interest? >>>>>=20 >>>>> =3D> I think we've (I'm including myself) highlighted several reasons >>>>> for why it makes little sense to transfer rules from HA to MN. >>>>> Instead of rat-holing on theory Vs practice, you (or others >>>>> advocating the other direction) need to come up with reasons for >>>>> doing things this way. This way we can think like engineers about >>>>> tradeoffs. >>>>> Absent that, I don't see any point in having theory Vs practice >>>>> high level discussions, which will lead nowhere. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Regards >>>>>> Yuri >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>> Subject: Re: [MEXT] Important considerations for directionality of >>>>>> flowbindings >>>>>>=20 >>>>>> Hi Pierrick, >>>>>>=20 >>>>>> On Jun 2, 2009, at 4:11 PM, wrot= e: >>>>>>=20 >>>>>>>=20 >>>>>>> Hi all, >>>>>>>=20 >>>>>>> Please see inline comment. >>>>>>>=20 >>>>>>> Regards, >>>>>>> Pierrick >>>>>>>=20 >>>>>>>> ________________________________________ >>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la >>>>>>>> part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 : >>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important considerations >>>>>>>> for directionality of flowbindings >>>>>>>>=20 >>>>>>>> Hesham, >>>>>>>> This is nice story and makes some sense for the discssion, >>>>>>>> however some details are ommited. In your adventure with the >>>>>>>> helpdesk, it (the >>>>>>>> helpdesk) is a third party service and thus your conclusions >>>>>>>> make sence. >>>>>>>> Think of the situation when superior of a heldesk person will >>>>>>>> tell him/her to check access point in some room. Would it be the >>>>>>>> same reaction? I assume not. By that I mean that if, for >>>>>>>> example, I'll install home agent in my home network, I can make >>>>>>>> it know anything I want about MN, and more intresting is that >>>>>>>> how I will do it, does not require any standardization. >>>>>>>> In other words, I'm superior of my HA. >>>>>>>> This situation is not unthinkable, I personally believe that >>>>>>>> this is much more efficient way of using HA fnctionality as >>>>>>>> opposed to big service providers who will have to fight with >>>>>>>> scalability and performance. >>>>>>>> However, one does not exclude another. >>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The difference between policy and rules is not only a matter of >>>>>>> conversion. A policy, is a static, or quasi-static, set of >>>>>>> guidance for the MN (e.g use access network X for application >>>>>>> type >>>>>>> A,...) while a rule update requires to be more dynamic. I mean: >>>>>>> eventually a policy could be updated depending on network >>>>>>> condition (e.g if X overloaded, use access network Y for >>>>>>> application type A,...) but a rule reacts on local triggers (e.g. >>>>>>> modification of the radio link >>>>>>> quality) with a shorter period of variation. So, IMHO, there is >>>>>>> no requirement for updating policy on a short period and >>>>>>> out-of-band mechanism can be used (e.g. IEEE 802.21 in push mode,..= .). >>>>>>=20 >>>>>> Fully agree! >>>>>> This is why I do not support the exchange of rules from the HA to th= e MN. >>>>>> Policies may be exchanged from the HA to the MN, but MIP is >>>>>> definitely not the protocol to transport them. >>>>>>=20 >>>>>> Nicolas >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> My 2 cents... >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Is there any reason to restrict where such convertion takes place? >>>>>>>> True >>>>>>>> that a HA does not know what is going on in the access network, >>>>>>>> on the other hand HA may know what is the network condition >>>>>>>> between HA and correspondent node. Either of this information is >>>>>>>> important, if not equally important. >>>>>>>> It is not really difficult to let an MN to reject rules sent by >>>>>>>> HA, which in my view would be quite natural. This implies that >>>>>>>> HA must follow the rules installed by MN until explicit >>>>>>>> acceptance has been received from MN. >>>>>>>> Such procedure is very similar to an MN beahviour when >>>>>>>> initiating new BU, where MN is not supposed to send any traffic >>>>>>>> before BU confirmation. >>>>>>>> BTW, what is the numerical representation of "rough consensus"? >>>>>>>> I assume is when majority is for, is it so? >>>>>>>> Yuri >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>>>>>> Behalf Of Hesham Soliman >>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>> To: mext >>>>>>>> Subject: [MEXT] Important considerations for directionality of >>>>>>>> flow bindings >>>>>>>>=20 >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>> I've always been a fan of the IETF's tradition of rough >>>>>>>> concensus (as opposed to voting). To me, this implies that you >>>>>>>> need to get your point across and get other people to see that poi= nt of >>>>>>>> view. >>>>>>>> As opposed to other organisations that require their members to >>>>>>>> vote and end up with rigid political positions. >>>>>>>>=20 >>>>>>>> The chairs asked us about the directionality question of the >>>>>>>> flows bindings. >>>>>>>> On the charter question, I said that the charter doesn't need to >>>>>>>> mention how a solution should work, but rather what problem >>>>>>>> needs to be solved. >>>>>>>> Hence, as far as the charter is concerned, I'm fine with >>>>>>>> transferring rules "between" the MN and HA without mentioning >>>>>>>> directions. >>>>>>>>=20 >>>>>>>> Nevertheless, we still need to agree on identifying the >>>>>>>> requirement for the solution. And when it comes to this, I'm >>>>>>>> strongly against voting and I'll practice this by explaining in >>>>>>>> this email why I think rules can not be transferred from the HA >>>>>>>> to the MN and that the only direction that makes sense in MIP is >>>>>>>> MN->HA. I'll deliberately ignore arguments like "some people >>>>>>>> MN->want >>>>>>>> this" or "an SDO wants this". They fall under the "meaningless wor= ds" >>>>>>>> category and I'm incapable of discussing them because they come >>>>>>>> with voting attitudes. They all need to be justified if the WG >>>>>>>> wants to have a technical _discussion_. >>>>>>>>=20 >>>>>>>> Here are my reasons: >>>>>>>>=20 >>>>>>>> 1. The HA does not know whether a CoA is tied to a certain >>>>>>>> access technology. It is one thing for the HA to send a message >>>>>>>> saying "forward port 80 traffic on a wifi link" (a policy) and a >>>>>>>> completely different thing to say "forward port 80 traffic using >>>>>>>> CoA 3ffe::1" >>>>>>>> (a rule). >>>>>>>>=20 >>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem now? The >>>>>>>> problem is that the HA has no idea about dynamic changes on that >>>>>>>> wifi link. It doesn't know if it's congested, it doesn't know >>>>>>>> what application is using port 80 (it doesn't have to be web >>>>>>>> traffic) or port 8000 for that matter and doesn't even know if >>>>>>>> the AP of that wifi link works at all. >>>>>>>> Finally, it >>>>>>>> doesn't know the user's policies or other admin policies for that = MN. >>>>>>>> This type of information needs to be sent regularly because it >>>>>>>> changes all the time and requires serious cross layer >>>>>>>> integration including sometimes layer 8 integration! It's complete= ly >>>>>>>> impractical. >>>>>>>>=20 >>>>>>>> 3. If the HA installed rules in the MN, what happens if the MN >>>>>>>> wants to change those rules. Say the wifi link went down, or the >>>>>>>> MN's wifi interface went down and it wants to move that traffic >>>>>>>> to another interface. Would the HA reject such move? Does the MN >>>>>>>> have to justify to the HA why it needs to move traffic? Does >>>>>>>> that involve writing a letter perhaps? >>>>>>>> If you say "well in that case, the HA should let the MN move the >>>>>>>> traffic" >>>>>>>> then I'll ask you: what's the point of having the HA install >>>>>>>> this stuff if it has no authority and how does it know the >>>>>>>> reason for the MN's movement of the flow? >>>>>>>> The way to control how users do things is to incentivise them >>>>>>>> with charging models and show them that things work better on >>>>>>>> certain technologies, not by installing rules that can't be >>>>>>>> followed. It's a broken mindset and we've known that it's broken >>>>>>>> for a long time. >>>>>>>>=20 >>>>>>>> 4. Some people mentioned that the HA should be able to revoke >>>>>>>> flows on the MN. I'm perfectly fine with that, just extend the >>>>>>>> binding revocation draft to handle flows and the rest is pretty >>>>>>>> straight forward. >>>>>>>>=20 >>>>>>>> Finally, I'll indulge in a true story that happened to me a few >>>>>>>> years ago when I found that my wifi link wasn't working in a >>>>>>>> hotel (no >>>>>>>> radio) >>>>>>>> and called the help desk. He insisted that the link was up an I >>>>>>>> insisted that it wasn't. When I asked him to tell me how he >>>>>>>> knows the link is up he said: I can ping the AP! Of course after >>>>>>>> another >>>>>>>> 5 minutes of trying to convince him that pinging the AP doesn't >>>>>>>> mean the radio is actually working he sent someone to the hotel >>>>>>>> who in turn realised that the radio was not working. >>>>>>>> For those people who want rules to be transferred from the HA to >>>>>>>> the MN, please think of your HA as this help desk person, i.e. >>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>=20 >>>>>>>> I hope this helps with the realisation that decisions can't be >>>>>>>> made here based on voting and that there is little merit to >>>>>>>> transferring rules from the HA to the MN. Policies can be >>>>>>>> transferred without any problems, but not rules. >>>>>>>>=20 >>>>>>>> Hesham >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From yuri.ismailov@ericsson.com Wed Jun 3 07:25:02 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4CF23A6B71 for ; Wed, 3 Jun 2009 07:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.049 X-Spam-Level: X-Spam-Status: No, score=-8.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 6HTCQV8VyEsp for ; Wed, 3 Jun 2009 07:25:00 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 905C13A6DDD for ; Wed, 3 Jun 2009 07:24:59 -0700 (PDT) X-AuditID: c1b4fb3e-b7b4bae00000395e-6a-4a2687ba18e7 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id C3.D1.14686.AB7862A4; Wed, 3 Jun 2009 16:24:58 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jun 2009 16:24:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 16:24:28 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0w References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 03 Jun 2009 14:24:29.0512 (UTC) FILETIME=[017E6C80:01C9E457] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 14:25:03 -0000 Hesham Missing is additional information which may be helpful in making better = decision about interface selection by MN. Which information is that I wrote in my previous emails. Back to my = examples (not all, do not want to repeat myself). If HA will have = changed traffic shaping parameters on one of the incoming or outgoing = interfaces, this will be important information for MN to know. We have agreed already that whether this information important or not, = benfitial or not is a matter of standpoint. I consider that knowing more is a benefit and will help to get better = result. My point is still the same. I see the reverse rules sending as = possibility to provide more information to the MN, thus make MN to get = to better decision about interface selection for its flows. This point = has not changed since the beginning of the discussion. /yuri -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Wednesday, June 03, 2009 4:09 PM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings On 3/06/09 10:47 PM, "Yuri Ismailov" wrote: > Ok, see your point, however:-) >=20 > The major difference here is that your are talking about CoA selection = > and I'm talking about interface selection. Quite a big difference. =3D> No, that's not the point really. The point is that there is no = relationship between CoA/interface selection on the MN and the upstream = ISP for the home network. > I do not see any grounds for MN to select CoA, based on what? Prefix = length? > While selection of an interface is based on expected characteristics=20 > of the communication. Routes (up/down)link in my opinion do have=20 > impact on the characteristics and this is exactly the information=20 > missing in the MN when selecting interface. =3D> There is nothing missing for the MN to make this selection. Please = tell us specifically what is missing. You're changing points on me all = the time now. Lets stick to one point at a time. What's missing? >=20 > Whenever, MN decides to move a flow, the reason can be anything but=20 > not which CoA it has configured on each interface. >=20 > Another thing is that MN will notice something e2e if and only if such = > support is implemented in the MN. =3D> Of course, so what? Moreover, this notice can not be made at IP layer. > TCP fights alone with all problems and never tells to any other layer=20 > what is going on. So what is left? Two options. Add this support to=20 > operating system, which makes its (support) existence questionable, or = > to applications, which is even more questionable. =3D> It's interesting that you think it's questionable to add the = support to the MN's OS but not questionable to add the support to the = HA's OS, which will not lead to the same reliability as if it were done = in the MN. It doesn't make sense to me. >=20 >>>=20 >>> Well, that's debatable, but this is clearly not a reason to do = anything. >>>=20 > Are you serious about that MIP may be broken because of that? =3D> Yes! It's not designed to do what you want to do. Luckily, in this = case what you want, IMO, is broken anyway so it's not a problem. Hesham >=20 > /yuri >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Wednesday, June 03, 2009 1:15 PM > To: Yuri Ismailov; Nicolas Montavont;=20 > pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of=20 > flowbindings >=20 >=20 >=20 >>=20 >> Still some answers, despite knowing that in your opinion they are not = >> benefits. >>=20 >> First of all MIP will not be breaked if the rules will be sent in=20 >> both directions. >=20 > =3D> Well, that's debatable, but this is clearly not a reason to do = anything. >=20 >>=20 >> - Access provider preferences relate to the use of backbone provider, = >> which may vary with the time of day. Changing backbone provider can=20 >> make quite big difference for commnication between HA (if HA service=20 >> is provided by the same access provider) and CN(s). The difference=20 >> can be expressed in, let's say, number of hops, load, possibly=20 >> something else. Such change is an event and may have an impact on the = >> overall communication. This can be told directly to MN or HA. Direct=20 >> communication to MN (if accepted as benefit:-)) in such case will=20 >> need standardization. Communication of this information to HA does=20 >> not (I consider this as a benefit). HA may act upon that event, and=20 >> the rest you >> know: rules in reverse direction. >=20 > =3D> There is no need to _tell_ the MN anything. There are two issues = here. > First, changing network conditions are best known e2e. So the MN will=20 > know that anyway based on the traffic running between it and the CN.=20 > The other issue is related to cost for certain times of day. This is a = > routing issue in the HA and has nothing to do with which interface the = > MN selects. The selected CoA has zero impact on the HA's upstream=20 > selection. Completely irrelevant actually. > Of course, as far as cost on the visited link, the MN knows best. >=20 >>=20 >> - Access provider may set up different parameters for traffic shaping = >> for each of HA interfaces. These preferences may vary independently=20 >> of change of backbone provider but dependently on the time of day.=20 >> The rest you know, whether it changes somebodies opinion. >=20 > =3D> But again, this has zero effect on CoA selection. The two issues=20 > are completely orthogonal. Selecting CoA1 or CoA2 has zero impact on=20 > the HA's upstream route. >=20 >>=20 >> - I presume that in RO mode this is similar to HA mode, and I'm in=20 >> when it comes to send rules in reverse direction between CN and MN. >> Benefits of doing that is that any change percieved by CN as=20 >> important to react upon can be expressed in proposal of new rules.=20 >> The sources causing changes may include but not limited to, are user, = >> network managemnt events, application generated events, etc. >>=20 >> So feel free to consider this as benefits or not >=20 > =3D> You seem to think that there is a relationship between upstream=20 > routing and CoA selection. That's not the case at all. These are two=20 > different addresses from two different networks. >=20 > Hesham >=20 >>=20 >> /yuri >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Wednesday, June 03, 2009 11:47 AM >> To: Yuri Ismailov; Nicolas Montavont;=20 >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of=20 >> flowbindings >>=20 >>=20 >>=20 >>=20 >> On 3/06/09 7:33 PM, "Yuri Ismailov" = wrote: >>=20 >>> Hesham, >>>=20 >>> Whenever we talk about sending additional information, the "waste of = >>> bandwidth" can be brought up. So I do not have an answer for that=20 >>> besides speculations around it. >>=20 >> =3D> no no, I don't mean it literally, I mean that the message = doesn't=20 >> do anything, i.e. Has no benefit. >>=20 >>>=20 >>> Speaking about benefits, everybody who knows the area is capable of=20 >>> turning things up side down. I assume it is subjective standpoint of = >>> considering things as benefits or disadvantages and all is about to=20 >>> agree or disagree. >>=20 >> =3D> That's fine, I'm asking for benefits in your opinion not someone = else's. >> It's impossible to discuss this if I can't see any benefits because=20 >> you didn't send any. What you sent were actions that can be done by=20 >> the HA and I responded by saying that the same (or more) information=20 >> is available to the MN. Therefore, if you think there are additional=20 >> benefits to doing this in the HA then you need to tell us. >>=20 >> The bottom line is this: MIP works by letting the MN install bindings = >> in the HA. If you want things to work in reverse you need to justify=20 >> it. I can't see any justifications because you're not answering my=20 >> questions on your scenarios. So, count me out on the reverse = direction :). >>=20 >>=20 >> For >>> me those I wrote about are benefits or potential benefits if you = want. >>=20 >> =3D> No you didn't. You wrote about things that can be done. Many=20 >> things can be done by many entities, the question is why the HA and = not the MN. >>=20 >>> One important thing in the discussion, although mentioned, but=20 >>> forgotten later is that by making rules distribution one way only,=20 >>> we do create limitation for benefits, or potential benefits if this=20 >>> sounds better. >>=20 >> =3D> Well, we won't know what we're missing unless someone tells us. = So=20 >> far no one has mentioned the advantages of doing things in the=20 >> reverse direction. >> There is always something missing from a protocol (it's engineering), = >> the question us whether it's significant or worth the trouble. >>=20 >> Hesham >>=20 >>>=20 >>> /yuri >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Wednesday, June 03, 2009 10:10 AM >>> To: Yuri Ismailov; Nicolas Montavont;=20 >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>> flowbindings >>>=20 >>> Yuri, >>>=20 >>> I can't parse those events you refer to. I'l answer both emails = here. >>> First the events you refer to: >>>=20 >>>>> - network condition towards CN(s) >>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>=20 >>> =3D> What's the event? A change in those conditions? The MN knows = the=20 >>> conditions of the e2e path as well as or better than the HA. What is = >>> the benefit of having the HA send a hint and how reliable is that=20 >>> hint anyway? >>>=20 >>>>> - Access provider (any access, not necessarily wireless) who=20 >>>>> offeres HA services preferences change >>>=20 >>> =3D> Preferences change to what?? How does it know if such change=20 >>> works for the MN at all? This is way too vague to be able to discuss = tradeoffs. >>>=20 >>>>> - Change of the access provider traffic to another backbone=20 >>>>> provider due to the time of the day. >>>>> - Traffic condition on HA interface, which accepts traffic from MN = >>>>> if MN sends on some particular local interface >>>=20 >>> =3D> These are path changes. The HA has _no idea_ how such a change=20 >>> affects each MN/CN combination and it's "hint" can cause more=20 >>> problems than it solves. BTW, if you're talking about hints then=20 >>> we're no longer talking about installing bindings in the MN. This is = >>> a different topic. MIP doesn't transfer hints, it pretty much sends = "orders" >>> from one end to another. >>>=20 >>> Now to the actions required by the MN: >>>=20 >>>> - reject, >>>> - re-evaluate and reject >>>> - re-evaluate and accept >>>> - accept >>>=20 >>> =3D> First, by assuming that the MN can reject the "hint" as you = call=20 >>> it you invalidate the whole argument for the HA to install rules. >>> Rejecting a hint or even evaluating it means that the MN knows more. >>> Therefore, the HA's hint is a complete waste of bandwidth. >>>=20 >>> I'm still confused about the _benefits_ you see here. Or are you=20 >>> assuming that the MN can't know those hints without the HA's=20 >>> involvement? But if you're assuming that, then how can it reject the = >>> hints? This whole proposal makes no sense to me at all. Not to=20 >>> mention the complexity you implicitly assume in order to generate=20 >>> those, hopefully reliable, hints. >>>=20 >>> Hesham >>>=20 >>>=20 >>> On 3/06/09 5:23 PM, "Yuri Ismailov" = wrote: >>>=20 >>>> Hesham, >>>>=20 >>>> In my view these are events not scenarious. These events are known=20 >>>> by HA but not MN. If HA acts upon events, given that it knows=20 >>>> somewhat more about MN, not only IP addresses, it (HA) can generate = >>>> new rules and send them as hint to MN. Back again, MN has four = options: >>>>=20 >>>> The benefit will be obviously that the new rules (if accepted) may=20 >>>> llead to a better overall communication characteristics. >>>>=20 >>>> /yuri >>>>=20 >>>>=20 >>>> =3D> I'm trying to understand what you mean above. These are all=20 >>>> scenarios, the question is: What is the benefit for the HA to=20 >>>> transfer rules? The HA will not know the path between the MN and CN = >>>> more than either node does. So I don't understand what _benefits_=20 >>>> you see here. >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> Pretty much sure that there are more examples and I encourage to=20 >>>>> think about those not from MN point of view but rather from the HA = >>>>> service provider. >>>>>=20 >>>>> /yuri >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>> pierrick.seite@orange-ftgroup.com >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of = >>>>> flowbindings >>>>>=20 >>>>> Yuri, >>>>>=20 >>>>> It is just rules TRANSFER which is the matter of MIP. So where >>>>>> is the logic when saying that MN to HA rules transfer is a=20 >>>>>> practical engineering and HA to MN is an academic interest? >>>>>=20 >>>>> =3D> I think we've (I'm including myself) highlighted several=20 >>>>> reasons for why it makes little sense to transfer rules from HA to = MN. >>>>> Instead of rat-holing on theory Vs practice, you (or others=20 >>>>> advocating the other direction) need to come up with reasons for=20 >>>>> doing things this way. This way we can think like engineers about=20 >>>>> tradeoffs. >>>>> Absent that, I don't see any point in having theory Vs practice=20 >>>>> high level discussions, which will lead nowhere. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Regards >>>>>> Yuri >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>> Subject: Re: [MEXT] Important considerations for directionality=20 >>>>>> of flowbindings >>>>>>=20 >>>>>> Hi Pierrick, >>>>>>=20 >>>>>> On Jun 2, 2009, at 4:11 PM, = wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> Hi all, >>>>>>>=20 >>>>>>> Please see inline comment. >>>>>>>=20 >>>>>>> Regards, >>>>>>> Pierrick >>>>>>>=20 >>>>>>>> ________________________________________ >>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la = >>>>>>>> part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 = : >>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important=20 >>>>>>>> considerations for directionality of flowbindings >>>>>>>>=20 >>>>>>>> Hesham, >>>>>>>> This is nice story and makes some sense for the discssion,=20 >>>>>>>> however some details are ommited. In your adventure with the=20 >>>>>>>> helpdesk, it (the >>>>>>>> helpdesk) is a third party service and thus your conclusions=20 >>>>>>>> make sence. >>>>>>>> Think of the situation when superior of a heldesk person will=20 >>>>>>>> tell him/her to check access point in some room. Would it be=20 >>>>>>>> the same reaction? I assume not. By that I mean that if, for=20 >>>>>>>> example, I'll install home agent in my home network, I can make = >>>>>>>> it know anything I want about MN, and more intresting is that=20 >>>>>>>> how I will do it, does not require any standardization. >>>>>>>> In other words, I'm superior of my HA. >>>>>>>> This situation is not unthinkable, I personally believe that=20 >>>>>>>> this is much more efficient way of using HA fnctionality as=20 >>>>>>>> opposed to big service providers who will have to fight with=20 >>>>>>>> scalability and performance. >>>>>>>> However, one does not exclude another. >>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The difference between policy and rules is not only a matter of=20 >>>>>>> conversion. A policy, is a static, or quasi-static, set of=20 >>>>>>> guidance for the MN (e.g use access network X for application=20 >>>>>>> type >>>>>>> A,...) while a rule update requires to be more dynamic. I mean: >>>>>>> eventually a policy could be updated depending on network=20 >>>>>>> condition (e.g if X overloaded, use access network Y for=20 >>>>>>> application type A,...) but a rule reacts on local triggers = (e.g. >>>>>>> modification of the radio link >>>>>>> quality) with a shorter period of variation. So, IMHO, there is=20 >>>>>>> no requirement for updating policy on a short period and=20 >>>>>>> out-of-band mechanism can be used (e.g. IEEE 802.21 in push = mode,...). >>>>>>=20 >>>>>> Fully agree! >>>>>> This is why I do not support the exchange of rules from the HA to = the MN. >>>>>> Policies may be exchanged from the HA to the MN, but MIP is=20 >>>>>> definitely not the protocol to transport them. >>>>>>=20 >>>>>> Nicolas >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> My 2 cents... >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Is there any reason to restrict where such convertion takes = place? >>>>>>>> True >>>>>>>> that a HA does not know what is going on in the access network, = >>>>>>>> on the other hand HA may know what is the network condition=20 >>>>>>>> between HA and correspondent node. Either of this information=20 >>>>>>>> is important, if not equally important. >>>>>>>> It is not really difficult to let an MN to reject rules sent by = >>>>>>>> HA, which in my view would be quite natural. This implies that=20 >>>>>>>> HA must follow the rules installed by MN until explicit=20 >>>>>>>> acceptance has been received from MN. >>>>>>>> Such procedure is very similar to an MN beahviour when=20 >>>>>>>> initiating new BU, where MN is not supposed to send any traffic = >>>>>>>> before BU confirmation. >>>>>>>> BTW, what is the numerical representation of "rough consensus"? >>>>>>>> I assume is when majority is for, is it so? >>>>>>>> Yuri >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 >>>>>>>> Behalf Of Hesham Soliman >>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>> To: mext >>>>>>>> Subject: [MEXT] Important considerations for directionality of=20 >>>>>>>> flow bindings >>>>>>>>=20 >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>> I've always been a fan of the IETF's tradition of rough=20 >>>>>>>> concensus (as opposed to voting). To me, this implies that you=20 >>>>>>>> need to get your point across and get other people to see that=20 >>>>>>>> point of view. >>>>>>>> As opposed to other organisations that require their members to = >>>>>>>> vote and end up with rigid political positions. >>>>>>>>=20 >>>>>>>> The chairs asked us about the directionality question of the=20 >>>>>>>> flows bindings. >>>>>>>> On the charter question, I said that the charter doesn't need=20 >>>>>>>> to mention how a solution should work, but rather what problem=20 >>>>>>>> needs to be solved. >>>>>>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>>>>>> transferring rules "between" the MN and HA without mentioning=20 >>>>>>>> directions. >>>>>>>>=20 >>>>>>>> Nevertheless, we still need to agree on identifying the=20 >>>>>>>> requirement for the solution. And when it comes to this, I'm=20 >>>>>>>> strongly against voting and I'll practice this by explaining in = >>>>>>>> this email why I think rules can not be transferred from the HA = >>>>>>>> to the MN and that the only direction that makes sense in MIP=20 >>>>>>>> is >>>>>>>> MN->HA. I'll deliberately ignore arguments like "some people=20 >>>>>>>> MN->want >>>>>>>> this" or "an SDO wants this". They fall under the "meaningless = words" >>>>>>>> category and I'm incapable of discussing them because they come = >>>>>>>> with voting attitudes. They all need to be justified if the WG=20 >>>>>>>> wants to have a technical _discussion_. >>>>>>>>=20 >>>>>>>> Here are my reasons: >>>>>>>>=20 >>>>>>>> 1. The HA does not know whether a CoA is tied to a certain=20 >>>>>>>> access technology. It is one thing for the HA to send a message = >>>>>>>> saying "forward port 80 traffic on a wifi link" (a policy) and=20 >>>>>>>> a completely different thing to say "forward port 80 traffic=20 >>>>>>>> using CoA 3ffe::1" >>>>>>>> (a rule). >>>>>>>>=20 >>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem now?=20 >>>>>>>> The problem is that the HA has no idea about dynamic changes on = >>>>>>>> that wifi link. It doesn't know if it's congested, it doesn't=20 >>>>>>>> know what application is using port 80 (it doesn't have to be=20 >>>>>>>> web >>>>>>>> traffic) or port 8000 for that matter and doesn't even know if=20 >>>>>>>> the AP of that wifi link works at all. >>>>>>>> Finally, it >>>>>>>> doesn't know the user's policies or other admin policies for = that MN. >>>>>>>> This type of information needs to be sent regularly because it=20 >>>>>>>> changes all the time and requires serious cross layer=20 >>>>>>>> integration including sometimes layer 8 integration! It's=20 >>>>>>>> completely impractical. >>>>>>>>=20 >>>>>>>> 3. If the HA installed rules in the MN, what happens if the MN=20 >>>>>>>> wants to change those rules. Say the wifi link went down, or=20 >>>>>>>> the MN's wifi interface went down and it wants to move that=20 >>>>>>>> traffic to another interface. Would the HA reject such move?=20 >>>>>>>> Does the MN have to justify to the HA why it needs to move=20 >>>>>>>> traffic? Does that involve writing a letter perhaps? >>>>>>>> If you say "well in that case, the HA should let the MN move=20 >>>>>>>> the traffic" >>>>>>>> then I'll ask you: what's the point of having the HA install=20 >>>>>>>> this stuff if it has no authority and how does it know the=20 >>>>>>>> reason for the MN's movement of the flow? >>>>>>>> The way to control how users do things is to incentivise them=20 >>>>>>>> with charging models and show them that things work better on=20 >>>>>>>> certain technologies, not by installing rules that can't be=20 >>>>>>>> followed. It's a broken mindset and we've known that it's=20 >>>>>>>> broken for a long time. >>>>>>>>=20 >>>>>>>> 4. Some people mentioned that the HA should be able to revoke=20 >>>>>>>> flows on the MN. I'm perfectly fine with that, just extend the=20 >>>>>>>> binding revocation draft to handle flows and the rest is pretty = >>>>>>>> straight forward. >>>>>>>>=20 >>>>>>>> Finally, I'll indulge in a true story that happened to me a few = >>>>>>>> years ago when I found that my wifi link wasn't working in a=20 >>>>>>>> hotel (no >>>>>>>> radio) >>>>>>>> and called the help desk. He insisted that the link was up an I = >>>>>>>> insisted that it wasn't. When I asked him to tell me how he=20 >>>>>>>> knows the link is up he said: I can ping the AP! Of course=20 >>>>>>>> after another >>>>>>>> 5 minutes of trying to convince him that pinging the AP doesn't = >>>>>>>> mean the radio is actually working he sent someone to the hotel = >>>>>>>> who in turn realised that the radio was not working. >>>>>>>> For those people who want rules to be transferred from the HA=20 >>>>>>>> to the MN, please think of your HA as this help desk person, = i.e. >>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>=20 >>>>>>>> I hope this helps with the realisation that decisions can't be=20 >>>>>>>> made here based on voting and that there is little merit to=20 >>>>>>>> transferring rules from the HA to the MN. Policies can be=20 >>>>>>>> transferred without any problems, but not rules. >>>>>>>>=20 >>>>>>>> Hesham >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From behcetsarikaya@yahoo.com Wed Jun 3 07:53:16 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C89E3A695B for ; Wed, 3 Jun 2009 07:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.815 X-Spam-Level: X-Spam-Status: No, score=-2.815 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 k9eeVpa6HUAq for ; Wed, 3 Jun 2009 07:53:14 -0700 (PDT) Received: from n7.bullet.re3.yahoo.com (n7.bullet.re3.yahoo.com [68.142.237.92]) by core3.amsl.com (Postfix) with SMTP id C8CAB3A67F9 for ; Wed, 3 Jun 2009 07:53:13 -0700 (PDT) Received: from [68.142.237.88] by n7.bullet.re3.yahoo.com with NNFMP; 03 Jun 2009 14:53:13 -0000 Received: from [67.195.9.83] by t4.bullet.re3.yahoo.com with NNFMP; 03 Jun 2009 14:53:12 -0000 Received: from [67.195.9.101] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 03 Jun 2009 14:53:12 -0000 Received: from [127.0.0.1] by omp105.mail.gq1.yahoo.com with NNFMP; 03 Jun 2009 14:53:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 669541.96772.bm@omp105.mail.gq1.yahoo.com Received: (qmail 7031 invoked by uid 60001); 3 Jun 2009 14:53:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1244040792; bh=3aWZj6HxJXkZg5ay9ZSDDtpnHu9mUq78gzguOxeT/mk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pYtROFKAeXDK72JFAM57FhH7c+7j1TcHTV70qmrPh9IFga5/04d44uSyIBgggmD+aqRrgonAGQuPUiSO9VThrz3khi4dvcseKaaDlSfkXC/ZH/YOEgtFeZuu2LF4l4vrZraMHp8aluLB7CC8PmQLt9GioL/ethFH1+OjopJa9Yc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=iL0leCSOcE/uX2uzn1WZVCgdW4foeJL4WBnHzD5dtd0U97jvRjUoNNTyTnykVbtKjbsioDQI4d6h6vAePaSNEokjBDlsV8mO/eH98rowvCNlOeHqlCjX5KH4Lwhg+su5oqx3iK5QUbV6EjR1/g+DGEUT5DZicw68KdrW0Csu/0U=; Message-ID: <547655.5587.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: C244jpsVM1lITUWItkeitbl09UmGm_h49oBJLHIywVbJU6MWC.7W2pTt5FV6KXq1jazruGC1G101STDhWej49mfWc0lEGUPce022MbjH9NSHHdDlRM7uZgy44f9l7Y2iyQiQhQ_WT2sQYo2Sr2cN8WpNNxK0TsNNsmeri2TMQe8d4eEI9Oie4oza0ZKl5ndTsMZB67GFVjZknVjgfUB4pAk8V5J6X2lAFoQDJQH.vTp9jrAK5mhkWcqa8JzpPCrGRQhG_0hlFx5lN1K_4FT95.p7I58rP.DN0Yk41u3MSCFd8yFNo2x7D4Y9bS0BoyzW99XvWkfC_YqPBPgukFSxjK7fumFZzqfYHJln Received: from [206.16.17.212] by web111410.mail.gq1.yahoo.com via HTTP; Wed, 03 Jun 2009 07:53:12 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: Date: Wed, 3 Jun 2009 07:53:12 -0700 (PDT) From: Behcet Sarikaya To: Hesham Soliman In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 14:53:16 -0000 I mentioned it as an example of HA to MN type of control.=0AI think it will= be good if you please stop disputing the charter which is coming from the = text you yourself agreed several years ago.=0AIs this a better advice?=0A= =0ABehcet=0A=0A=0A----- Original Message ----=0AFrom: Hesham Soliman =0ATo: Behcet Sarikaya ; George Tsir= tsis =0ACc: mext@ietf.org=0ASent: Tuesday, June 2,= 2009 9:57:53 PM=0ASubject: Re: [MEXT] Important considerations for directi= onality of flowbindings=0A=0ABehcet, =0A=0AYou don't understand the discuss= ion. We're not talking about binding=0Arevocation, everyone agrees that the= HA can revoke a flow binding. So stop=0Areferring to RFCs that are not bei= ng disputed...=0A=0A=0A=0A=0AOn 3/06/09 2:42 AM, "Behcet Sarikaya" wrote:=0A=0A> =0A> Yes IETF has already standardized "th= eoretical possibilities" with RFC 3543 in=0A> 2003, why not another one tha= t was inherited from one of the founding fathers=0A> of mext called monami6= ?=0A> =0A> =0A> =A0=0A> =0A> =0A> ----- Original Message ----=0A> From: Geo= rge Tsirtsis =0A> To: Behcet Sarikaya =0A> Cc: Nicolas Montavont ; mext@ietf.org=0A> S= ent: Tuesday, June 2, 2009 11:22:35 AM=0A> Subject: Re: [MEXT] Important co= nsiderations for directionality of=0A> flowbindings=0A> =0A> A lot of thing= s are theoretically possible.=0A> We are not here, however, to standardise = all theoretical possibilities.=0A> =0A> On Tue, Jun 2, 2009 at 5:19 PM, Beh= cet Sarikaya=0A> wrote:=0A>> =0A>> First it was:= =0A>> No HA can not do, only MN can do it.=0A>> =0A>> =0A>> Now it suddenly= became:=0A>> Yes it is possible but academic :).=0A>> =0A>> =0A>> =0A>> Re= gards,=0A>> =0A>> Behcet=0A>> =0A>> =0A>> =0A>> ----- Original Message ----= =0A>> From: George Tsirtsis =0A>> To: Nicolas Mont= avont =0A>> Cc: mext@ietf.org=0A>> Sent: Tuesday, June = 2, 2009 10:54:50 AM=0A>> Subject: Re: [MEXT] Important considerations for d= irectionality of=0A>> flowbindings=0A>> =0A>> FWIW I also fully agree with = this as well as with Hesham's main points.=0A>> =0A>> Although I understand= that some people find the prospect of an HA=0A>> micromanaging uplink flow= s interesting at an academic level, I do not=0A>> think anyone would seriou= sly consider this in a practical deployment=0A>> for reasons that have alre= ady been exhaustively articulated.=0A>> =0A>> Regards=0A>> George=0A>> =0A>= > =0A>> =0A>> On Tue, Jun 2, 2009 at 4:46 PM, Nicolas Montavont wrote:=0A>>> Hi Pierrick,=0A>>> =0A>>> On Jun 2, 2009, at 4:11 PM= , wrote:=0A>>> =0A>>>> =0A>>>> Hi all,= =0A>>>> =0A>>>> Please see inline comment.=0A>>>> =0A>>>> Regards,=0A>>>> P= ierrick=0A>>>> =0A>>>>> ________________________________________=0A>>>>> De= : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de=0A>>>= >> Yuri Ismailov=0A>>>>> Envoy=E9 : vendredi 29 mai 2009 09:35=0A>>>>> =C0 = : Hesham Soliman; mext=0A>>>>> Objet : Re: [MEXT] Important considerations = for directionality of=0A>>>>> flowbindings=0A>>>>> =0A>>>>> Hesham,=0A>>>>>= This is nice story and makes some sense for the discssion, however some=0A= >>>>> details are ommited. In your adventure with the helpdesk, it (the=0A>= >>>> helpdesk) is a third party service and thus your conclusions make senc= e.=0A>>>>> Think of the situation when superior of a heldesk person will te= ll=0A>>>>> him/her=0A>>>>> to check access point in some room. Would it be = the same reaction? I=0A>>>>> assume not. By that I mean that if, for exampl= e, I'll install home agent=0A>>>>> in my home network, I can make it know a= nything I want about MN, and more=0A>>>>> intresting is that how I will do = it, does not require any=0A>>>>> standardization.=0A>>>>> In other words, I= 'm superior of my HA.=0A>>>>> This situation is not unthinkable, I personal= ly believe that this is much=0A>>>>> more efficient way of using HA fnction= ality as opposed to big service=0A>>>>> providers who will have to fight wi= th scalability and performance.=0A>>>>> However, one does not exclude anoth= er.=0A>>>>> Difference between policies and rules is a convertion step.=0A>= >>>> =0A>>>>> =0A>>>> =0A>>>> =0A>>>> The difference between policy and rul= es is not only a matter of=0A>>>> conversion. A policy, is a static, or qua= si-static, set of guidance for the=0A>>>> MN (e.g use access network X for = application type A,...) while a rule=0A>>>> update=0A>>>> requires to be mo= re dynamic. I mean: eventually a policy could be updated=0A>>>> depending o= n network condition (e.g if X overloaded, use access network Y=0A>>>> for a= pplication type A,...) but a rule reacts on local triggers (e.g.=0A>>>> mod= ification of the radio link quality) with a shorter period of variation.=0A= >>>> So, IMHO, there is no requirement for updating policy on a short perio= d and=0A>>>> out-of-band mechanism can be used (e.g. IEEE 802..21 in push m= ode,...).=0A>>> =0A>>> Fully agree!=0A>>> This is why I do not support the = exchange of rules from the HA to the MN.=0A>>> Policies may be exchanged fr= om the HA to the MN, but MIP is definitely not=0A>>> the protocol to transp= ort them.=0A>>> =0A>>> Nicolas=0A>>> =0A>>>> =0A>>>> =0A>>>> My 2 cents...= =0A>>>> =0A>>>>> =0A>>>>> Is there any reason to restrict where such conver= tion takes place? True=0A>>>>> that a HA does not know what is going on in = the access network, on the=0A>>>>> other hand HA may know what is the netwo= rk condition between HA and=0A>>>>> correspondent node. Either of this info= rmation is important, if not=0A>>>>> equally important.=0A>>>>> It is not r= eally difficult to let an MN to reject rules sent by HA, which=0A>>>>> in m= y view would be quite natural. This implies that HA must follow the=0A>>>>>= rules installed by MN until explicit acceptance has been received from=0A>= >>>> MN.=0A>>>>> Such procedure is very similar to an MN beahviour when ini= tiating new BU,=0A>>>>> where MN is not supposed to send any traffic before= BU confirmation.=0A>>>>> BTW, what is the numerical representation of "rou= gh consensus"? I assume=0A>>>>> is when majority is for, is it so?=0A>>>>> = Yuri=0A>>>>> =0A>>>>> =0A>>>>> -----Original Message-----=0A>>>>> From: mex= t-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of=0A>>>>> Hesh= am Soliman=0A>>>>> Sent: Thursday, May 28, 2009 12:07 PM=0A>>>>> To: mext= =0A>>>>> Subject: [MEXT] Important considerations for directionality of flo= w=0A>>>>> bindings=0A>>>>> =0A>>>>> Hi all,=0A>>>>> =0A>>>>> I've always be= en a fan of the IETF's tradition of rough concensus (as=0A>>>>> opposed to = voting).. To me, this implies that you need to get your point=0A>>>>> acros= s and get other people to see that point of view. As opposed to=0A>>>>> oth= er organisations that require their members to vote and end up with=0A>>>>>= rigid political positions.=0A>>>>> =0A>>>>> The chairs asked us about the = directionality question of the flows=0A>>>>> bindings.=0A>>>>> On the chart= er question, I said that the charter doesn't need to mention=0A>>>>> how a = solution should work, but rather what problem needs to be solved.=0A>>>>> H= ence, as far as the charter is concerned, I'm fine with transferring=0A>>>>= > rules "between" the MN and HA without mentioning directions.=0A>>>>> =0A>= >>>> Nevertheless, we still need to agree on identifying the requirement fo= r=0A>>>>> the solution. And when it comes to this, I'm strongly against vot= ing and=0A>>>>> I'll practice this by explaining in this email why I think = rules can not=0A>>>>> be transferred from the HA to the MN and that the onl= y direction that=0A>>>>> makes sense in MIP is MN->HA. I'll deliberately ig= nore arguments like=0A>>>>> "some people want this" or "an SDO wants this".= They fall under the=0A>>>>> "meaningless words"=0A>>>>> category and I'm i= ncapable of discussing them because they come with=0A>>>>> voting attitudes= .. They all need to be justified if the WG wants to have=0A>>>>> a technical= _discussion_.=0A>>>>> =0A>>>>> Here are my reasons:=0A>>>>> =0A>>>>> 1. Th= e HA does not know whether a CoA is tied to a certain access=0A>>>>> techno= logy. It is one thing for the HA to send a message saying "forward=0A>>>>> = port 80 traffic on a wifi link" (a policy) and a completely different=0A>>>= >> thing to say "forward port 80 traffic using CoA 3ffe::1" (a rule).=0A>>>= >> =0A>>>>> 2. You might argue that the HA can be told by the MN that 3ffe:= :1 is=0A>>>>> tied to a wifi access, so what's the problem now? The problem= is that=0A>>>>> the HA has no idea about dynamic changes on that wifi link= ... It doesn't=0A>>>>> know if it's congested, it doesn't know what applicat= ion is using port=0A>>>>> 80 (it doesn't have to be web traffic) or port 80= 00 for that matter and=0A>>>>> doesn't even know if the AP of that wifi lin= k works at all. Finally, it=0A>>>>> doesn't know the user's policies or oth= er admin policies for that MN.=0A>>>>> This type of information needs to be= sent regularly because it changes=0A>>>>> all the time and requires seriou= s cross layer integration including=0A>>>>> sometimes layer 8 integration! = It's completely impractical.=0A>>>>> =0A>>>>> 3. If the HA installed rules = in the MN, what happens if the MN wants to=0A>>>>> change those rules. Say = the wifi link went down, or the MN's wifi=0A>>>>> interface went down and i= t wants to move that traffic to another=0A>>>>> interface. Would the HA rej= ect such move? Does the MN have to justify to=0A>>>>> the HA why it needs t= o move traffic? Does that involve writing a letter=0A>>>>> perhaps?=0A>>>>>= If you say "well in that case, the HA should let the MN move the=0A>>>>> t= raffic"=0A>>>>> then I'll ask you: what's the point of having the HA instal= l this stuff=0A>>>>> if it has no authority and how does it know the reason= for the MN's=0A>>>>> movement of the flow?=0A>>>>> The way to control how = users do things is to incentivise them with=0A>>>>> charging models and sho= w them that things work better on certain=0A>>>>> technologies, not by inst= alling rules that can't be followed. It's a=0A>>>>> broken mindset and we'v= e known that it's broken for a long time.=0A>>>>> =0A>>>>> 4. Some people m= entioned that the HA should be able to revoke flows on=0A>>>>> the MN. I'm = perfectly fine with that, just extend the binding revocation=0A>>>>> draft = to handle flows and the rest is pretty straight forward.=0A>>>>> =0A>>>>> F= inally, I'll indulge in a true story that happened to me a few years=0A>>>>= > ago when I found that my wifi link wasn't working in a hotel (no radio)= =0A>>>>> and called the help desk. He insisted that the link was up an I in= sisted=0A>>>>> that it wasn't. When I asked him to tell me how he knows the= link is up=0A>>>>> he said: I can ping the AP! Of course after another 5 m= inutes of trying=0A>>>>> to convince him that pinging the AP doesn't mean t= he radio is actually=0A>>>>> working he sent someone to the hotel who in tu= rn realised that the radio=0A>>>>> was not working.=0A>>>>> For those peopl= e who want rules to be transferred from the HA to the MN,=0A>>>>> please th= ink of your HA as this help desk person, i.e. it has no clue=0A>>>>> about = what's happening at the other end.=0A>>>>> =0A>>>>> I hope this helps with = the realisation that decisions can't be made here=0A>>>>> based on voting a= nd that there is little merit to transferring rules=0A>>>>> from the HA to = the MN. Policies can be transferred without any problems,=0A>>>>> but not r= ules.=0A>>>>> =0A>>>>> Hesham=0A>>>>> =0A>>>>> =0A>>>>> =0A>>>>> =0A>>>>> = =0A>>>>> _______________________________________________=0A>>>>> MEXT maili= ng list=0A>>>>> MEXT@ietf.org=0A>>>>> https://www.ietf..org/mailman/listinf= o/mext=0A>>>>> _______________________________________________=0A>>>>> MEXT= mailing list=0A>>>>> MEXT@ietf.org=0A>>>>> https://www.ietf.org/mailman/li= stinfo/mext=0A>>>> =0A>>>> _______________________________________________= =0A>>>> MEXT mailing list=0A>>>> MEXT@ietf.org=0A>>>> https://www.ietf.org/= mailman/listinfo/mext=0A>>> =0A>>> ________________________________________= _______=0A>>> MEXT mailing list=0A>>> MEXT@ietf.org=0A>>> https://www.ietf.= org/mailman/listinfo/mext=0A>>> =0A>> _____________________________________= __________=0A>> MEXT mailing list=0A>> MEXT@ietf.org=0A>> https://www.ietf.= org/mailman/listinfo/mext=0A>> =0A>> =0A>> =0A>> =0A>> =0A>> =0A> =0A> =0A>= =0A>=A0 =A0 =A0 =0A> =0A> _______________________________________________= =0A> MEXT mailing list=0A> MEXT@ietf.org=0A> https://www.ietf.org/mailman/l= istinfo/mext=0A=0A=0A From behcetsarikaya@yahoo.com Wed Jun 3 15:53:26 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 859433A6964 for ; Wed, 3 Jun 2009 15:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 vszAomGIOFdE for ; Wed, 3 Jun 2009 15:53:25 -0700 (PDT) Received: from n10.bullet.re3.yahoo.com (n10.bullet.re3.yahoo.com [68.142.237.123]) by core3.amsl.com (Postfix) with SMTP id 366453A67AD for ; Wed, 3 Jun 2009 15:53:25 -0700 (PDT) Received: from [68.142.230.28] by n10.bullet.re3.yahoo.com with NNFMP; 03 Jun 2009 22:53:25 -0000 Received: from [67.195.9.83] by t1.bullet.re2.yahoo.com with NNFMP; 03 Jun 2009 22:53:25 -0000 Received: from [67.195.9.109] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 03 Jun 2009 22:53:25 -0000 Received: from [127.0.0.1] by omp113.mail.gq1.yahoo.com with NNFMP; 03 Jun 2009 22:52:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 155452.35289.bm@omp113.mail.gq1.yahoo.com Received: (qmail 18703 invoked by uid 60001); 3 Jun 2009 22:53:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1244069604; bh=NARsgSnkQk1D0sveS0dKvCsE5Qy+4T2BvpoHtmZ9Dus=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZLlisAYmOfe7M5aS7QZCGYO+3VO/I+eYsm+A5K2cMQtn7+BPcP850SSGhZ+6Ync1dCzRwFvVg83AkqvWZa2ZcKLEn/R3KVW9hZfxXBO0/M8TdJCcQjvO2tfFq308F5AxTqoMk/+p04cF7AuL7K7N4B2uLiSotK6Iq5IpPcFgt4c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=m0ULfn1G1WuAvi52Y6LiDKpS/PPQkoBrVjZWyTaPYN/WfVznNXlWik3wTPP6qinU6eXz+Bh/ZMM9oAqbhy7xZPTQu+eaOJ+DNqj1p5tU8EroJxzz125T6fIeSHIM1IzHsXX4SeUc4oGI4vZyL+9nJ56W5YMJVUP+joB8jbZqMSk=; Message-ID: <917142.17893.qm@web111412.mail.gq1.yahoo.com> X-YMail-OSG: Ag3mKgUVM1lPWgd1EKSZQ2.rLIQDI8oLBTpg4mQzrvP2NuykkoIY6SOK_i3hhBW9Qakf6taSOJhFUnNDcN1hlWCXrehCXb2cG.WDt6qY.0mZkZDBkZHBWORKVHn4lath55BHM2E3P3anSnzJv1nNBlP3ftfzyFJPUNNBM.wSnB1z.JLS19hit93ksfjON3iK9JMEPxe50t5Nv.mQ1fGLeuHs4bI.6CU7qd5fgrknxkdV8D4kALxyYd7qpnAiiJgKRUfnymnO.tlW6c.dIRag91QBxPri6tmBKkE9HZNhcmWj_BldBGdgNNuEY8r.jmiJ1MoNrQ-- Received: from [206.16.17.212] by web111412.mail.gq1.yahoo.com via HTTP; Wed, 03 Jun 2009 15:53:24 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <20090527174501.61D493A6CF6@core3.amsl.com> Date: Wed, 3 Jun 2009 15:53:24 -0700 (PDT) From: Behcet Sarikaya To: RYUJI WAKIKAWA , mext@ietf.org In-Reply-To: <20090527174501.61D493A6CF6@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-14.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 22:53:26 -0000 Hi Ryuji,=0A=A0 Regarding Section 4.3, =0A=A0 Simultaneous Home and Foreign= Binding (H) flag=0A=0A=A0=A0=A0=A0=A0 This flag indicates that the mobile = node registers multiple=0A=A0=A0=A0=A0=A0 bindings to the home agent while = it is attached to the home link.=0A=A0=A0=A0=A0=A0 This flag is valid only = for a Binding Update sent to the home=0A=A0=A0=A0=A0=A0 agent.=0A=0Aas we d= iscussed before, HA will reject BUs sent at home link (source address=3DHoA= )=A0if lifetime field is not zero. =0AI don't think H flag-thing can be mad= e to work.=0A=0AThe suggestion was to introduce a BU option flag for this p= urpose not a mobility option flag. =0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A--= --- Original Message ----=0AFrom: "Internet-Drafts@ietf.org" =0ATo: i-d-announce@ietf.org=0ACc: mext@ietf.org=0ASent: Wednes= day, May 27, 2009 12:45:01 PM=0ASubject: [MEXT] I-D Action:draft-ietf-monam= i6-multiplecoa-14.txt=0A=0AA New Internet-Draft is available from the on-li= ne Internet-Drafts directories.=0AThis draft is a work item of the Mobility= EXTensions for IPv6 Working Group of the IETF.=0A=0A=0A=A0=A0=A0 Title=A0 = =A0 =A0 =A0 =A0 : Multiple Care-of Addresses Registration=0A=A0=A0=A0 Autho= r(s)=A0 =A0 =A0 : R. Wakikawa, et al.=0A=A0=A0=A0 Filename=A0 =A0 =A0 =A0 := draft-ietf-monami6-multiplecoa-14.txt=0A=A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0= : 44=0A=A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2009-05-27=0A=0AAccording t= o the current Mobile IPv6 specification, a mobile node may=0Ahave several c= are-of addresses, but only one, called the primary=0Acare-of address, that = can be registered with its home agent and the=0Acorrespondent nodes.=A0 How= ever, for matters of cost, bandwidth, delay,=0Aetc, it is useful for the mo= bile node to get Internet access through=0Amultiple accesses simultaneously= , in which case the mobile node would=0Abe configured with multiple active = IPv6 care-of addresses.=A0 This=0Adocument proposes extensions to the Mobil= e IPv6 protocol to register=0Aand use multiple care-of addresses.=A0 The ex= tensions proposed in this=0Adocument can be used by Mobile Routers using th= e NEMO (Network=0AMobility) Basic Support protocol as well.=0A=0AA URL for = this Internet-Draft is:=0Ahttp://www.ietf.org/internet-drafts/draft-ietf-mo= nami6-multiplecoa-14.txt=0A=0AInternet-Drafts are also available by anonymo= us FTP at:=0Aftp://ftp.ietf.org/internet-drafts/=0A=0ABelow is the data whi= ch will enable a MIME compliant mail reader=0Aimplementation to automatical= ly retrieve the ASCII version of the=0AInternet-Draft.=0A=0A=0A=0A From hesham@elevatemobile.com Wed Jun 3 19:00:41 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF9A528C16A for ; Wed, 3 Jun 2009 19:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.335 X-Spam-Level: X-Spam-Status: No, score=-3.335 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 DFNgPJB+qYvO for ; Wed, 3 Jun 2009 19:00:39 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id A42DE3A6941 for ; Wed, 3 Jun 2009 19:00:37 -0700 (PDT) Received: from [115.130.34.78] by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MC2Fh-00015x-2S; Thu, 04 Jun 2009 12:00:28 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 04 Jun 2009 12:00:09 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 02:00:41 -0000 Yuri, > Missing is additional information which may be helpful in making better > decision about interface selection by MN. > Which information is that I wrote in my previous emails. Back to my examp= les > (not all, do not want to repeat myself). If HA will have changed traffic > shaping parameters on one of the incoming or outgoing interfaces, this wi= ll be > important information for MN to know. > We have agreed already that whether this information important or not, > benfitial or not is a matter of standpoint. =3D> I don't agree or like to think that it's a matter of standpoint. That's why I asked you on every point you raised and compared this to the MN's knowledge on e2e basis. Once we have "standpoints" then we're getting outside the technical realm. The reason I don't think it's useful is that this information cannot be used by the MN to select a CoA. I've already stated that before and you seemed to agree so I don't know why you repeat this as a reason for the HA to install filters in the MN. Let me say it again: There is no correlation between the routing on the HA's upstream interfaces/ISP with the MN's selection of a CoA. > I consider that knowing more is a benefit and will help to get better res= ult. >=20 > My point is still the same. I see the reverse rules sending as possibilit= y to > provide more information to the MN, thus make MN to get to better decisio= n > about interface selection for its flows. This point has not changed since= the > beginning of the discussion. =3D> This is why we're not making progress IMO: 1. The hints you refer to are not the same things as installing rules on th= e MN. Completely different information in fact. You've essentially proved tha= t when you suggested that the MN can accept or reject them. So, let's not cal= l them rules. The more direct word for what you want to send is policies 2. You didn't provide a valid scenario that we can discuss as to why it's needed or how it could work. I've asked numerous questions in each email that were not answered (with the exception of the last email). It's not possible to progress the discussion without answering each others' questions. You can go back through the threads and verify this. 3. If we're sending rules from the HA to the MN and the MN can reject those rules then the whole exercise is pointless. You really want to send policie= s not rules. I can imagine those policies being one of the inputs that the MN uses to make a decision. I still fail to see how anything happening on the HA's upstream interfaces/ISP link can possibly influence the MN's decision for CoA selection. This is another unanswered question. Hesham >=20 > /yuri >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Wednesday, June 03, 2009 4:09 PM > To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of > flowbindings >=20 >=20 >=20 >=20 > On 3/06/09 10:47 PM, "Yuri Ismailov" wrote: >=20 >> Ok, see your point, however:-) >>=20 >> The major difference here is that your are talking about CoA selection >> and I'm talking about interface selection. Quite a big difference. >=20 > =3D> No, that's not the point really. The point is that there is no relatio= nship > between CoA/interface selection on the MN and the upstream ISP for the ho= me > network. >=20 >> I do not see any grounds for MN to select CoA, based on what? Prefix len= gth? >> While selection of an interface is based on expected characteristics >> of the communication. Routes (up/down)link in my opinion do have >> impact on the characteristics and this is exactly the information >> missing in the MN when selecting interface. >=20 > =3D> There is nothing missing for the MN to make this selection. Please tel= l us > specifically what is missing. You're changing points on me all the time n= ow. > Lets stick to one point at a time. What's missing? >=20 >>=20 >> Whenever, MN decides to move a flow, the reason can be anything but >> not which CoA it has configured on each interface. >>=20 >> Another thing is that MN will notice something e2e if and only if such >> support is implemented in the MN. >=20 > =3D> Of course, so what? >=20 > Moreover, this notice can not be made at IP layer. >> TCP fights alone with all problems and never tells to any other layer >> what is going on. So what is left? Two options. Add this support to >> operating system, which makes its (support) existence questionable, or >> to applications, which is even more questionable. >=20 > =3D> It's interesting that you think it's questionable to add the support t= o the > MN's OS but not questionable to add the support to the HA's OS, which wil= l not > lead to the same reliability as if it were done in the MN. It doesn't mak= e > sense to me. >=20 >>=20 >>>>=20 >>>> Well, that's debatable, but this is clearly not a reason to do anythin= g. >>>>=20 >> Are you serious about that MIP may be broken because of that? >=20 > =3D> Yes! It's not designed to do what you want to do. Luckily, in this cas= e > what you want, IMO, is broken anyway so it's not a problem. >=20 > Hesham >=20 >>=20 >> /yuri >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Wednesday, June 03, 2009 1:15 PM >> To: Yuri Ismailov; Nicolas Montavont; >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of >> flowbindings >>=20 >>=20 >>=20 >>>=20 >>> Still some answers, despite knowing that in your opinion they are not >>> benefits. >>>=20 >>> First of all MIP will not be breaked if the rules will be sent in >>> both directions. >>=20 >> =3D> Well, that's debatable, but this is clearly not a reason to do anythi= ng. >>=20 >>>=20 >>> - Access provider preferences relate to the use of backbone provider, >>> which may vary with the time of day. Changing backbone provider can >>> make quite big difference for commnication between HA (if HA service >>> is provided by the same access provider) and CN(s). The difference >>> can be expressed in, let's say, number of hops, load, possibly >>> something else. Such change is an event and may have an impact on the >>> overall communication. This can be told directly to MN or HA. Direct >>> communication to MN (if accepted as benefit:-)) in such case will >>> need standardization. Communication of this information to HA does >>> not (I consider this as a benefit). HA may act upon that event, and >>> the rest you >>> know: rules in reverse direction. >>=20 >> =3D> There is no need to _tell_ the MN anything. There are two issues here= . >> First, changing network conditions are best known e2e. So the MN will >> know that anyway based on the traffic running between it and the CN. >> The other issue is related to cost for certain times of day. This is a >> routing issue in the HA and has nothing to do with which interface the >> MN selects. The selected CoA has zero impact on the HA's upstream >> selection. Completely irrelevant actually. >> Of course, as far as cost on the visited link, the MN knows best. >>=20 >>>=20 >>> - Access provider may set up different parameters for traffic shaping >>> for each of HA interfaces. These preferences may vary independently >>> of change of backbone provider but dependently on the time of day. >>> The rest you know, whether it changes somebodies opinion. >>=20 >> =3D> But again, this has zero effect on CoA selection. The two issues >> are completely orthogonal. Selecting CoA1 or CoA2 has zero impact on >> the HA's upstream route. >>=20 >>>=20 >>> - I presume that in RO mode this is similar to HA mode, and I'm in >>> when it comes to send rules in reverse direction between CN and MN. >>> Benefits of doing that is that any change percieved by CN as >>> important to react upon can be expressed in proposal of new rules. >>> The sources causing changes may include but not limited to, are user, >>> network managemnt events, application generated events, etc. >>>=20 >>> So feel free to consider this as benefits or not >>=20 >> =3D> You seem to think that there is a relationship between upstream >> routing and CoA selection. That's not the case at all. These are two >> different addresses from two different networks. >>=20 >> Hesham >>=20 >>>=20 >>> /yuri >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Wednesday, June 03, 2009 11:47 AM >>> To: Yuri Ismailov; Nicolas Montavont; >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of >>> flowbindings >>>=20 >>>=20 >>>=20 >>>=20 >>> On 3/06/09 7:33 PM, "Yuri Ismailov" wrote: >>>=20 >>>> Hesham, >>>>=20 >>>> Whenever we talk about sending additional information, the "waste of >>>> bandwidth" can be brought up. So I do not have an answer for that >>>> besides speculations around it. >>>=20 >>> =3D> no no, I don't mean it literally, I mean that the message doesn't >>> do anything, i.e. Has no benefit. >>>=20 >>>>=20 >>>> Speaking about benefits, everybody who knows the area is capable of >>>> turning things up side down. I assume it is subjective standpoint of >>>> considering things as benefits or disadvantages and all is about to >>>> agree or disagree. >>>=20 >>> =3D> That's fine, I'm asking for benefits in your opinion not someone els= e's. >>> It's impossible to discuss this if I can't see any benefits because >>> you didn't send any. What you sent were actions that can be done by >>> the HA and I responded by saying that the same (or more) information >>> is available to the MN. Therefore, if you think there are additional >>> benefits to doing this in the HA then you need to tell us. >>>=20 >>> The bottom line is this: MIP works by letting the MN install bindings >>> in the HA. If you want things to work in reverse you need to justify >>> it. I can't see any justifications because you're not answering my >>> questions on your scenarios. So, count me out on the reverse direction = :). >>>=20 >>>=20 >>> For >>>> me those I wrote about are benefits or potential benefits if you want. >>>=20 >>> =3D> No you didn't. You wrote about things that can be done. Many >>> things can be done by many entities, the question is why the HA and not= the >>> MN. >>>=20 >>>> One important thing in the discussion, although mentioned, but >>>> forgotten later is that by making rules distribution one way only, >>>> we do create limitation for benefits, or potential benefits if this >>>> sounds better. >>>=20 >>> =3D> Well, we won't know what we're missing unless someone tells us. So >>> far no one has mentioned the advantages of doing things in the >>> reverse direction. >>> There is always something missing from a protocol (it's engineering), >>> the question us whether it's significant or worth the trouble. >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> /yuri >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Wednesday, June 03, 2009 10:10 AM >>>> To: Yuri Ismailov; Nicolas Montavont; >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of >>>> flowbindings >>>>=20 >>>> Yuri, >>>>=20 >>>> I can't parse those events you refer to. I'l answer both emails here. >>>> First the events you refer to: >>>>=20 >>>>>> - network condition towards CN(s) >>>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>>=20 >>>> =3D> What's the event? A change in those conditions? The MN knows the >>>> conditions of the e2e path as well as or better than the HA. What is >>>> the benefit of having the HA send a hint and how reliable is that >>>> hint anyway? >>>>=20 >>>>>> - Access provider (any access, not necessarily wireless) who >>>>>> offeres HA services preferences change >>>>=20 >>>> =3D> Preferences change to what?? How does it know if such change >>>> works for the MN at all? This is way too vague to be able to discuss >>>> tradeoffs. >>>>=20 >>>>>> - Change of the access provider traffic to another backbone >>>>>> provider due to the time of the day. >>>>>> - Traffic condition on HA interface, which accepts traffic from MN >>>>>> if MN sends on some particular local interface >>>>=20 >>>> =3D> These are path changes. The HA has _no idea_ how such a change >>>> affects each MN/CN combination and it's "hint" can cause more >>>> problems than it solves. BTW, if you're talking about hints then >>>> we're no longer talking about installing bindings in the MN. This is >>>> a different topic. MIP doesn't transfer hints, it pretty much sends >>>> "orders" >>>> from one end to another. >>>>=20 >>>> Now to the actions required by the MN: >>>>=20 >>>>> - reject, >>>>> - re-evaluate and reject >>>>> - re-evaluate and accept >>>>> - accept >>>>=20 >>>> =3D> First, by assuming that the MN can reject the "hint" as you call >>>> it you invalidate the whole argument for the HA to install rules. >>>> Rejecting a hint or even evaluating it means that the MN knows more. >>>> Therefore, the HA's hint is a complete waste of bandwidth. >>>>=20 >>>> I'm still confused about the _benefits_ you see here. Or are you >>>> assuming that the MN can't know those hints without the HA's >>>> involvement? But if you're assuming that, then how can it reject the >>>> hints? This whole proposal makes no sense to me at all. Not to >>>> mention the complexity you implicitly assume in order to generate >>>> those, hopefully reliable, hints. >>>>=20 >>>> Hesham >>>>=20 >>>>=20 >>>> On 3/06/09 5:23 PM, "Yuri Ismailov" wrote= : >>>>=20 >>>>> Hesham, >>>>>=20 >>>>> In my view these are events not scenarious. These events are known >>>>> by HA but not MN. If HA acts upon events, given that it knows >>>>> somewhat more about MN, not only IP addresses, it (HA) can generate >>>>> new rules and send them as hint to MN. Back again, MN has four option= s: >>>>>=20 >>>>> The benefit will be obviously that the new rules (if accepted) may >>>>> llead to a better overall communication characteristics. >>>>>=20 >>>>> /yuri >>>>>=20 >>>>>=20 >>>>> =3D> I'm trying to understand what you mean above. These are all >>>>> scenarios, the question is: What is the benefit for the HA to >>>>> transfer rules? The HA will not know the path between the MN and CN >>>>> more than either node does. So I don't understand what _benefits_ >>>>> you see here. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>>=20 >>>>>> Pretty much sure that there are more examples and I encourage to >>>>>> think about those not from MN point of view but rather from the HA >>>>>> service provider. >>>>>>=20 >>>>>> /yuri >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>> pierrick.seite@orange-ftgroup.com >>>>>> Cc: mext@ietf.org >>>>>> Subject: Re: [MEXT] Important considerations for directionality of >>>>>> flowbindings >>>>>>=20 >>>>>> Yuri, >>>>>>=20 >>>>>> It is just rules TRANSFER which is the matter of MIP. So where >>>>>>> is the logic when saying that MN to HA rules transfer is a >>>>>>> practical engineering and HA to MN is an academic interest? >>>>>>=20 >>>>>> =3D> I think we've (I'm including myself) highlighted several >>>>>> reasons for why it makes little sense to transfer rules from HA to M= N. >>>>>> Instead of rat-holing on theory Vs practice, you (or others >>>>>> advocating the other direction) need to come up with reasons for >>>>>> doing things this way. This way we can think like engineers about >>>>>> tradeoffs. >>>>>> Absent that, I don't see any point in having theory Vs practice >>>>>> high level discussions, which will lead nowhere. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Regards >>>>>>> Yuri >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>> of flowbindings >>>>>>>=20 >>>>>>> Hi Pierrick, >>>>>>>=20 >>>>>>> On Jun 2, 2009, at 4:11 PM, wro= te: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>> Please see inline comment. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Pierrick >>>>>>>>=20 >>>>>>>>> ________________________________________ >>>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la >>>>>>>>> part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 : >>>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important >>>>>>>>> considerations for directionality of flowbindings >>>>>>>>>=20 >>>>>>>>> Hesham, >>>>>>>>> This is nice story and makes some sense for the discssion, >>>>>>>>> however some details are ommited. In your adventure with the >>>>>>>>> helpdesk, it (the >>>>>>>>> helpdesk) is a third party service and thus your conclusions >>>>>>>>> make sence. >>>>>>>>> Think of the situation when superior of a heldesk person will >>>>>>>>> tell him/her to check access point in some room. Would it be >>>>>>>>> the same reaction? I assume not. By that I mean that if, for >>>>>>>>> example, I'll install home agent in my home network, I can make >>>>>>>>> it know anything I want about MN, and more intresting is that >>>>>>>>> how I will do it, does not require any standardization. >>>>>>>>> In other words, I'm superior of my HA. >>>>>>>>> This situation is not unthinkable, I personally believe that >>>>>>>>> this is much more efficient way of using HA fnctionality as >>>>>>>>> opposed to big service providers who will have to fight with >>>>>>>>> scalability and performance. >>>>>>>>> However, one does not exclude another. >>>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The difference between policy and rules is not only a matter of >>>>>>>> conversion. A policy, is a static, or quasi-static, set of >>>>>>>> guidance for the MN (e.g use access network X for application >>>>>>>> type >>>>>>>> A,...) while a rule update requires to be more dynamic. I mean: >>>>>>>> eventually a policy could be updated depending on network >>>>>>>> condition (e.g if X overloaded, use access network Y for >>>>>>>> application type A,...) but a rule reacts on local triggers (e.g. >>>>>>>> modification of the radio link >>>>>>>> quality) with a shorter period of variation. So, IMHO, there is >>>>>>>> no requirement for updating policy on a short period and >>>>>>>> out-of-band mechanism can be used (e.g. IEEE 802.21 in push mode,.= ..). >>>>>>>=20 >>>>>>> Fully agree! >>>>>>> This is why I do not support the exchange of rules from the HA to t= he >>>>>>> MN. >>>>>>> Policies may be exchanged from the HA to the MN, but MIP is >>>>>>> definitely not the protocol to transport them. >>>>>>>=20 >>>>>>> Nicolas >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> My 2 cents... >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Is there any reason to restrict where such convertion takes place= ? >>>>>>>>> True >>>>>>>>> that a HA does not know what is going on in the access network, >>>>>>>>> on the other hand HA may know what is the network condition >>>>>>>>> between HA and correspondent node. Either of this information >>>>>>>>> is important, if not equally important. >>>>>>>>> It is not really difficult to let an MN to reject rules sent by >>>>>>>>> HA, which in my view would be quite natural. This implies that >>>>>>>>> HA must follow the rules installed by MN until explicit >>>>>>>>> acceptance has been received from MN. >>>>>>>>> Such procedure is very similar to an MN beahviour when >>>>>>>>> initiating new BU, where MN is not supposed to send any traffic >>>>>>>>> before BU confirmation. >>>>>>>>> BTW, what is the numerical representation of "rough consensus"? >>>>>>>>> I assume is when majority is for, is it so? >>>>>>>>> Yuri >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>>>>>>> Behalf Of Hesham Soliman >>>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>>> To: mext >>>>>>>>> Subject: [MEXT] Important considerations for directionality of >>>>>>>>> flow bindings >>>>>>>>>=20 >>>>>>>>> Hi all, >>>>>>>>>=20 >>>>>>>>> I've always been a fan of the IETF's tradition of rough >>>>>>>>> concensus (as opposed to voting). To me, this implies that you >>>>>>>>> need to get your point across and get other people to see that >>>>>>>>> point of view. >>>>>>>>> As opposed to other organisations that require their members to >>>>>>>>> vote and end up with rigid political positions. >>>>>>>>>=20 >>>>>>>>> The chairs asked us about the directionality question of the >>>>>>>>> flows bindings. >>>>>>>>> On the charter question, I said that the charter doesn't need >>>>>>>>> to mention how a solution should work, but rather what problem >>>>>>>>> needs to be solved. >>>>>>>>> Hence, as far as the charter is concerned, I'm fine with >>>>>>>>> transferring rules "between" the MN and HA without mentioning >>>>>>>>> directions. >>>>>>>>>=20 >>>>>>>>> Nevertheless, we still need to agree on identifying the >>>>>>>>> requirement for the solution. And when it comes to this, I'm >>>>>>>>> strongly against voting and I'll practice this by explaining in >>>>>>>>> this email why I think rules can not be transferred from the HA >>>>>>>>> to the MN and that the only direction that makes sense in MIP >>>>>>>>> is >>>>>>>>> MN->HA. I'll deliberately ignore arguments like "some people >>>>>>>>> MN->want >>>>>>>>> this" or "an SDO wants this". They fall under the "meaningless wo= rds" >>>>>>>>> category and I'm incapable of discussing them because they come >>>>>>>>> with voting attitudes. They all need to be justified if the WG >>>>>>>>> wants to have a technical _discussion_. >>>>>>>>>=20 >>>>>>>>> Here are my reasons: >>>>>>>>>=20 >>>>>>>>> 1. The HA does not know whether a CoA is tied to a certain >>>>>>>>> access technology. It is one thing for the HA to send a message >>>>>>>>> saying "forward port 80 traffic on a wifi link" (a policy) and >>>>>>>>> a completely different thing to say "forward port 80 traffic >>>>>>>>> using CoA 3ffe::1" >>>>>>>>> (a rule). >>>>>>>>>=20 >>>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem now? >>>>>>>>> The problem is that the HA has no idea about dynamic changes on >>>>>>>>> that wifi link. It doesn't know if it's congested, it doesn't >>>>>>>>> know what application is using port 80 (it doesn't have to be >>>>>>>>> web >>>>>>>>> traffic) or port 8000 for that matter and doesn't even know if >>>>>>>>> the AP of that wifi link works at all. >>>>>>>>> Finally, it >>>>>>>>> doesn't know the user's policies or other admin policies for that= MN. >>>>>>>>> This type of information needs to be sent regularly because it >>>>>>>>> changes all the time and requires serious cross layer >>>>>>>>> integration including sometimes layer 8 integration! It's >>>>>>>>> completely impractical. >>>>>>>>>=20 >>>>>>>>> 3. If the HA installed rules in the MN, what happens if the MN >>>>>>>>> wants to change those rules. Say the wifi link went down, or >>>>>>>>> the MN's wifi interface went down and it wants to move that >>>>>>>>> traffic to another interface. Would the HA reject such move? >>>>>>>>> Does the MN have to justify to the HA why it needs to move >>>>>>>>> traffic? Does that involve writing a letter perhaps? >>>>>>>>> If you say "well in that case, the HA should let the MN move >>>>>>>>> the traffic" >>>>>>>>> then I'll ask you: what's the point of having the HA install >>>>>>>>> this stuff if it has no authority and how does it know the >>>>>>>>> reason for the MN's movement of the flow? >>>>>>>>> The way to control how users do things is to incentivise them >>>>>>>>> with charging models and show them that things work better on >>>>>>>>> certain technologies, not by installing rules that can't be >>>>>>>>> followed. It's a broken mindset and we've known that it's >>>>>>>>> broken for a long time. >>>>>>>>>=20 >>>>>>>>> 4. Some people mentioned that the HA should be able to revoke >>>>>>>>> flows on the MN. I'm perfectly fine with that, just extend the >>>>>>>>> binding revocation draft to handle flows and the rest is pretty >>>>>>>>> straight forward. >>>>>>>>>=20 >>>>>>>>> Finally, I'll indulge in a true story that happened to me a few >>>>>>>>> years ago when I found that my wifi link wasn't working in a >>>>>>>>> hotel (no >>>>>>>>> radio) >>>>>>>>> and called the help desk. He insisted that the link was up an I >>>>>>>>> insisted that it wasn't. When I asked him to tell me how he >>>>>>>>> knows the link is up he said: I can ping the AP! Of course >>>>>>>>> after another >>>>>>>>> 5 minutes of trying to convince him that pinging the AP doesn't >>>>>>>>> mean the radio is actually working he sent someone to the hotel >>>>>>>>> who in turn realised that the radio was not working. >>>>>>>>> For those people who want rules to be transferred from the HA >>>>>>>>> to the MN, please think of your HA as this help desk person, i.e. >>>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>>=20 >>>>>>>>> I hope this helps with the realisation that decisions can't be >>>>>>>>> made here based on voting and that there is little merit to >>>>>>>>> transferring rules from the HA to the MN. Policies can be >>>>>>>>> transferred without any problems, but not rules. >>>>>>>>>=20 >>>>>>>>> Hesham >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> MEXT@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> MEXT@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From w52006@huawei.com Wed Jun 3 20:25:28 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F269A3A6A75 for ; Wed, 3 Jun 2009 20:25:27 -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=[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 UFJLRrm0fH-8 for ; Wed, 3 Jun 2009 20:25:27 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id AE3E43A69B0 for ; Wed, 3 Jun 2009 20:25:26 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKP005582UFHQ@szxga02-in.huawei.com> for mext@ietf.org; Thu, 04 Jun 2009 11:25:27 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKP006F52UFKB@szxga02-in.huawei.com> for mext@ietf.org; Thu, 04 Jun 2009 11:25:27 +0800 (CST) Received: from w52006d ([10.164.12.17]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKP006RT2UBVJ@szxml04-in.huawei.com> for mext@ietf.org; Thu, 04 Jun 2009 11:25:27 +0800 (CST) Date: Thu, 04 Jun 2009 11:25:23 +0800 From: w52006 In-reply-to: To: 'Hesham Soliman' , 'Yuri Ismailov' , 'Nicolas Montavont' , pierrick.seite@orange-ftgroup.com Message-id: <00a701c9e4c4$18ba5f40$110ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAEkbfA= Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 03:25:28 -0000 Hello Hesham Reading through your comments, I get two main points here and provide my comments below. 1. Presumably you believe MN could/would always determine the optimized path in different network condition, and HA knows nothing. You know, whatever it is, flow binding is driven by MIP-above function (such as connect manager, app, etc). According to RFC1122, MS (host) may be simple or intelligent, which is also concerned in the MIF WG. Why do you think MN is that intelligent on flow management? I don't think so. On the contrary, I think, HA should be capable to adjust the forwarding path on behalf of network operator or HA service provider. (even if MN is very intelligent). That's, there are three types of operations for flow binding on HA: a) may accept/reject MN's flow binding request; or b) may initiate flow binding to MN; (e.g. MN has registered MCoA, but does not bind any flow; that's, all traffic flows are over the primary CoA); or c) may initiate flow binding to hand off flow from one interface to another (e.g. HA is aware of access network congestion based on BFD-like mechanism. Please see more cases as Yuri mentioned) Further, how HA knows App is up to how you (operator) identify App. 2. No benefits to flow rules exchange from HA to MN. I think, one of the important benefits is that HA could adjust the forwarding path for MN on behalf of network operator or HA service provider. Moreover, I observe one of your argumentation is "MN may change it if relavent link/interface is down, etc.". I think it is obviously not enough to prove anything. B.R. Yungui From hesham@elevatemobile.com Wed Jun 3 21:04:32 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B663A6AA9 for ; Wed, 3 Jun 2009 21:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[AWL=-0.401, 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 C36dOi6jU3ku for ; Wed, 3 Jun 2009 21:04:31 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 2CFEB3A6ADA for ; Wed, 3 Jun 2009 21:04:30 -0700 (PDT) Received: from [115.130.34.78] by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MC4Bg-0000jH-K5; Thu, 04 Jun 2009 14:04:23 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 04 Jun 2009 14:04:11 +1000 From: Hesham Soliman To: , 'Yuri Ismailov' , 'Nicolas Montavont' , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAEkbfAAKpIMjA== In-Reply-To: <00a701c9e4c4$18ba5f40$110ca40a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 04:04:32 -0000 On 4/06/09 1:25 PM, "w52006" wrote: > Hello Hesham > > Reading through your comments, I get two main points here and > provide my comments below. > > 1. Presumably you believe MN could/would always determine the > optimized path in different network condition, and HA knows nothing. => The HA knows nothing about the criteria that the MN will use to make the decision. In your email below you didn't explain what the HA knows. More below. > > You know, whatever it is, flow binding is driven by MIP-above function > (such as connect manager, app, etc). According to RFC1122, MS > (host) may be simple or intelligent, which is also concerned in the > MIF WG. Why do you think MN is that intelligent on flow > management? I don't think so. => Because it knows everything it needs to make the decision. You still didn't say what it doesn't know. > On the contrary, I think, HA should be capable to adjust the forwarding => "should be capable"? This sounds like a wish. On what basis is the HA capable of making that decision? This is a very simple question that you need to answer before you can proceed with suggesting protocol messages. > path on behalf of network operator or HA service provider. (even if MN > is very intelligent). That's, there are three types of operations for flow > binding on HA: > a) may accept/reject MN's flow binding request; or => Yes it can reject it of course like it does with any other binding. It can also revoke it. > b) may initiate flow binding to MN; (e.g. MN has registered MCoA, > but does not bind any flow; that's, all traffic flows are over the primary > CoA); or => On what basis? How does it decide that? > c) may initiate flow binding to hand off flow from one interface to > another (e.g. HA is aware of access network congestion based on > BFD-like mechanism. Please see more cases as Yuri mentioned) => Completely unworkable. I already responded to Yuri's emails, feel free to respond to that. I don't want to repeat myself. > > Further, how HA knows App is up to how you (operator) identify App. => huh? The operator doesn't identify apps and if it tried to identify apps it's a guess based on historical data. The MN KNOWS the apps. > > > 2. No benefits to flow rules exchange from HA to MN. > > I think, one of the important benefits is that HA could adjust the > forwarding path for MN on behalf of network operator or HA service > provider. => I've answered this point 3 times already. Please respond to those answers. We can't keep repeating reasons that have already been shown to be wrong unless you prove me wrong. > > Moreover, I observe one of your argumentation is "MN may change > it if relavent link/interface is down, etc.". I think it is obviously not > enough to prove anything. => ?? I can't parse this. Hesham > > B.R. > Yungui > > From pierrick.seite@orange-ftgroup.com Thu Jun 4 06:15:44 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 733403A6E7B for ; Thu, 4 Jun 2009 06:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 qziOHx3Or1fj for ; Thu, 4 Jun 2009 06:15:43 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id EF5A83A6A91 for ; Thu, 4 Jun 2009 06:15:42 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 15:14:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jun 2009 15:14:36 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462191AD1@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality offlowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAEkbfAAKpIMjAAS309g References: <00a701c9e4c4$18ba5f40$110ca40a@china.huawei.com> From: To: , , , X-OriginalArrivalTime: 04 Jun 2009 13:14:38.0335 (UTC) FILETIME=[69C550F0:01C9E516] Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality offlowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 13:15:44 -0000 Hi, Please see inline comments. Regards, Pierrick > -----Message d'origine----- > De : Hesham Soliman [mailto:hesham@elevatemobile.com] > Envoy=E9 : jeudi 4 juin 2009 06:04 > =C0 : w52006@huawei.com; 'Yuri Ismailov'; 'Nicolas Montavont'; SEITE > Pierrick RD-RESA-REN > Cc : mext@ietf.org > Objet : Re: [MEXT] Important considerations for directionality > offlowbindings >=20 >=20 >=20 >=20 > On 4/06/09 1:25 PM, "w52006" wrote: >=20 > > Hello Hesham > > > > Reading through your comments, I get two main points here and > > provide my comments below. > > > > 1. Presumably you believe MN could/would always determine the > > optimized path in different network condition, and HA knows nothing. >=20 > =3D> The HA knows nothing about the criteria that the MN will use to = make > the > decision. In your email below you didn't explain what the HA knows. = More > below. >=20 > > > > You know, whatever it is, flow binding is driven by MIP-above = function > > (such as connect manager, app, etc). According to RFC1122, MS > > (host) may be simple or intelligent, which is also concerned in the > > MIF WG. Why do you think MN is that intelligent on flow > > management? I don't think so. >=20 I definitely agree that a decision function is required to manage flow = binding but, IMHO, who and how is making the decision is independent = from the mobility execution protocol (i.e. MIP). Here, we just need to = consider that policies/rules are available at the HA and MN side but I = think that how these rules/policies are derived is out of scope in this = discussion. Am I missing something?=20 > =3D> Because it knows everything it needs to make the decision.=20 I agree. Actually there are different models for the decision = architecture. Even if it could be possible for the HA to enforce the = decision to the MN, I don't think it is the best way to do. The MN = should be involved in the decision making process because it knows about = local criteria for making the decision (e.g. applications running, user = preferences, accesses available, quality of the communication = links,...). Of course, it does not exclude the case where the decision = process is shared between the MN and the network where a dedicated = entity (it can be the HA but not necessary) provides policies and/or = recommendation to the MN but the later should make the final decision = for above reason. However as I said before, I think that discussion with = regards to decision is out of scope here.... =20 > You still > didn't say what it doesn't know. >=20 > > On the contrary, I think, HA should be capable to adjust the = forwarding >=20 > =3D> "should be capable"? This sounds like a wish. On what basis is = the HA > capable of making that decision? This is a very simple question that = you > need to answer before you can proceed with suggesting protocol = messages. >=20 > > path on behalf of network operator or HA service provider. (even if = MN > > is very intelligent). That's, there are three types of operations = for > flow > > binding on HA: > > a) may accept/reject MN's flow binding request; or >=20 > =3D> Yes it can reject it of course like it does with any other = binding. It > can also revoke it. >=20 > > b) may initiate flow binding to MN; (e.g. MN has registered MCoA, > > but does not bind any flow; that's, all traffic flows are over the > primary > > CoA); or >=20 > =3D> On what basis? How does it decide that? >=20 > > c) may initiate flow binding to hand off flow from one interface to > > another (e.g. HA is aware of access network congestion based on > > BFD-like mechanism. Please see more cases as Yuri mentioned) >=20 > =3D> Completely unworkable. I already responded to Yuri's emails, feel = free > to > respond to that. I don't want to repeat myself. >=20 > > > > Further, how HA knows App is up to how you (operator) identify App. >=20 > =3D> huh? The operator doesn't identify apps and if it tried to = identify > apps > it's a guess based on historical data. The MN KNOWS the apps. >=20 > > > > > > 2. No benefits to flow rules exchange from HA to MN. > > > > I think, one of the important benefits is that HA could adjust the > > forwarding path for MN on behalf of network operator or HA service > > provider. >=20 > =3D> I've answered this point 3 times already. Please respond to those > answers. We can't keep repeating reasons that have already been shown = to > be > wrong unless you prove me wrong. >=20 > > > > Moreover, I observe one of your argumentation is "MN may change > > it if relavent link/interface is down, etc.". I think it is = obviously > not > > enough to prove anything. >=20 > =3D> ?? I can't parse this. >=20 > Hesham >=20 > > > > B.R. > > Yungui > > > > >=20 From yuri.ismailov@ericsson.com Thu Jun 4 07:02:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C792E3A6D34 for ; Thu, 4 Jun 2009 07:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.067 X-Spam-Level: X-Spam-Status: No, score=-8.067 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 q6Dlsy9c5h9h for ; Thu, 4 Jun 2009 07:02:11 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5AD0D3A6A1F for ; Thu, 4 Jun 2009 07:02:10 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9cae00000140d-44-4a27d3c4963e Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 9C.63.05133.4C3D72A4; Thu, 4 Jun 2009 16:01:40 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jun 2009 16:01:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jun 2009 16:01:16 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIA== References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 04 Jun 2009 14:01:18.0133 (UTC) FILETIME=[EE949650:01C9E51C] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 14:02:13 -0000 Hesham, I provided several scenarious which you said are invalid. This is where = my conclusion about standpoint comes from. Whether you call hints policies or rules it does not change what = information can be provided by HA to MN. There were many arguments that ploicies may be sent to mn but not rules. = For me rules is instantiation of policies evaluated based on an event. By sending rules HA does not install anything in MN. Likewise, MN does = not install rules in HA, it informs HA about currently made choices. As = I remember rules will not be valid until proper Ack arrival, which for = me means that may not be instantiated at all. Niether rules nor polices are specific to MIP. As I wrote those can be = exchanged between hosts without any MIP implementation, just for access = selection purposes. Once it was decided to make it as part of MIP = protocol, I'm fine with that. Do not have any idea to discuss this, = while personally consider that the work on rules transfer can very well = fit into the MEXT group but as a separate work item, but this is not the = case now, so good enough the way it is. And back again, it really gets repeated, so will lead to nowhere, you've = got my arguments and tell that the information, which I'm talking about, = is not usefull. What can I say more? I can put you on my position and = start asking questions instead of answering. So, why it is not usefull? /yuri -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Thursday, June 04, 2009 4:00 AM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings Yuri, > Missing is additional information which may be helpful in making=20 > better decision about interface selection by MN. > Which information is that I wrote in my previous emails. Back to my=20 > examples (not all, do not want to repeat myself). If HA will have=20 > changed traffic shaping parameters on one of the incoming or outgoing=20 > interfaces, this will be important information for MN to know. > We have agreed already that whether this information important or not, = > benfitial or not is a matter of standpoint. =3D> I don't agree or like to think that it's a matter of standpoint. = That's why I asked you on every point you raised and compared this to = the MN's knowledge on e2e basis. Once we have "standpoints" then we're = getting outside the technical realm. The reason I don't think it's = useful is that this information cannot be used by the MN to select a = CoA. I've already stated that before and you seemed to agree so I don't = know why you repeat this as a reason for the HA to install filters in = the MN. Let me say it again: There is no correlation between the routing on the HA's upstream = interfaces/ISP with the MN's selection of a CoA. > I consider that knowing more is a benefit and will help to get better = result. >=20 > My point is still the same. I see the reverse rules sending as=20 > possibility to provide more information to the MN, thus make MN to get = > to better decision about interface selection for its flows. This point = > has not changed since the beginning of the discussion. =3D> This is why we're not making progress IMO: 1. The hints you refer to are not the same things as installing rules on = the MN. Completely different information in fact. You've essentially = proved that when you suggested that the MN can accept or reject them. = So, let's not call them rules. The more direct word for what you want to = send is policies 2. You didn't provide a valid scenario that we can discuss as to why = it's needed or how it could work. I've asked numerous questions in each = email that were not answered (with the exception of the last email). = It's not possible to progress the discussion without answering each = others' questions. You can go back through the threads and verify this. 3. If we're sending rules from the HA to the MN and the MN can reject = those rules then the whole exercise is pointless. You really want to = send policies not rules. I can imagine those policies being one of the = inputs that the MN uses to make a decision. I still fail to see how = anything happening on the HA's upstream interfaces/ISP link can possibly = influence the MN's decision for CoA selection. This is another = unanswered question. Hesham >=20 > /yuri >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Wednesday, June 03, 2009 4:09 PM > To: Yuri Ismailov; Nicolas Montavont;=20 > pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of=20 > flowbindings >=20 >=20 >=20 >=20 > On 3/06/09 10:47 PM, "Yuri Ismailov" = wrote: >=20 >> Ok, see your point, however:-) >>=20 >> The major difference here is that your are talking about CoA=20 >> selection and I'm talking about interface selection. Quite a big = difference. >=20 > =3D> No, that's not the point really. The point is that there is no=20 > relationship between CoA/interface selection on the MN and the=20 > upstream ISP for the home network. >=20 >> I do not see any grounds for MN to select CoA, based on what? Prefix = length? >> While selection of an interface is based on expected characteristics=20 >> of the communication. Routes (up/down)link in my opinion do have=20 >> impact on the characteristics and this is exactly the information=20 >> missing in the MN when selecting interface. >=20 > =3D> There is nothing missing for the MN to make this selection. = Please=20 > tell us specifically what is missing. You're changing points on me all = the time now. > Lets stick to one point at a time. What's missing? >=20 >>=20 >> Whenever, MN decides to move a flow, the reason can be anything but=20 >> not which CoA it has configured on each interface. >>=20 >> Another thing is that MN will notice something e2e if and only if=20 >> such support is implemented in the MN. >=20 > =3D> Of course, so what? >=20 > Moreover, this notice can not be made at IP layer. >> TCP fights alone with all problems and never tells to any other layer = >> what is going on. So what is left? Two options. Add this support to=20 >> operating system, which makes its (support) existence questionable,=20 >> or to applications, which is even more questionable. >=20 > =3D> It's interesting that you think it's questionable to add the=20 > support to the MN's OS but not questionable to add the support to the=20 > HA's OS, which will not lead to the same reliability as if it were=20 > done in the MN. It doesn't make sense to me. >=20 >>=20 >>>>=20 >>>> Well, that's debatable, but this is clearly not a reason to do = anything. >>>>=20 >> Are you serious about that MIP may be broken because of that? >=20 > =3D> Yes! It's not designed to do what you want to do. Luckily, in = this=20 > case what you want, IMO, is broken anyway so it's not a problem. >=20 > Hesham >=20 >>=20 >> /yuri >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Wednesday, June 03, 2009 1:15 PM >> To: Yuri Ismailov; Nicolas Montavont;=20 >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of=20 >> flowbindings >>=20 >>=20 >>=20 >>>=20 >>> Still some answers, despite knowing that in your opinion they are=20 >>> not benefits. >>>=20 >>> First of all MIP will not be breaked if the rules will be sent in=20 >>> both directions. >>=20 >> =3D> Well, that's debatable, but this is clearly not a reason to do = anything. >>=20 >>>=20 >>> - Access provider preferences relate to the use of backbone=20 >>> provider, which may vary with the time of day. Changing backbone=20 >>> provider can make quite big difference for commnication between HA=20 >>> (if HA service is provided by the same access provider) and CN(s).=20 >>> The difference can be expressed in, let's say, number of hops, load, = >>> possibly something else. Such change is an event and may have an=20 >>> impact on the overall communication. This can be told directly to MN = >>> or HA. Direct communication to MN (if accepted as benefit:-)) in=20 >>> such case will need standardization. Communication of this=20 >>> information to HA does not (I consider this as a benefit). HA may=20 >>> act upon that event, and the rest you >>> know: rules in reverse direction. >>=20 >> =3D> There is no need to _tell_ the MN anything. There are two issues = here. >> First, changing network conditions are best known e2e. So the MN will = >> know that anyway based on the traffic running between it and the CN. >> The other issue is related to cost for certain times of day. This is=20 >> a routing issue in the HA and has nothing to do with which interface=20 >> the MN selects. The selected CoA has zero impact on the HA's upstream = >> selection. Completely irrelevant actually. >> Of course, as far as cost on the visited link, the MN knows best. >>=20 >>>=20 >>> - Access provider may set up different parameters for traffic=20 >>> shaping for each of HA interfaces. These preferences may vary=20 >>> independently of change of backbone provider but dependently on the = time of day. >>> The rest you know, whether it changes somebodies opinion. >>=20 >> =3D> But again, this has zero effect on CoA selection. The two issues = >> are completely orthogonal. Selecting CoA1 or CoA2 has zero impact on=20 >> the HA's upstream route. >>=20 >>>=20 >>> - I presume that in RO mode this is similar to HA mode, and I'm in=20 >>> when it comes to send rules in reverse direction between CN and MN. >>> Benefits of doing that is that any change percieved by CN as=20 >>> important to react upon can be expressed in proposal of new rules. >>> The sources causing changes may include but not limited to, are=20 >>> user, network managemnt events, application generated events, etc. >>>=20 >>> So feel free to consider this as benefits or not >>=20 >> =3D> You seem to think that there is a relationship between upstream=20 >> routing and CoA selection. That's not the case at all. These are two=20 >> different addresses from two different networks. >>=20 >> Hesham >>=20 >>>=20 >>> /yuri >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Wednesday, June 03, 2009 11:47 AM >>> To: Yuri Ismailov; Nicolas Montavont;=20 >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>> flowbindings >>>=20 >>>=20 >>>=20 >>>=20 >>> On 3/06/09 7:33 PM, "Yuri Ismailov" = wrote: >>>=20 >>>> Hesham, >>>>=20 >>>> Whenever we talk about sending additional information, the "waste=20 >>>> of bandwidth" can be brought up. So I do not have an answer for=20 >>>> that besides speculations around it. >>>=20 >>> =3D> no no, I don't mean it literally, I mean that the message = doesn't=20 >>> do anything, i.e. Has no benefit. >>>=20 >>>>=20 >>>> Speaking about benefits, everybody who knows the area is capable of = >>>> turning things up side down. I assume it is subjective standpoint=20 >>>> of considering things as benefits or disadvantages and all is about = >>>> to agree or disagree. >>>=20 >>> =3D> That's fine, I'm asking for benefits in your opinion not = someone else's. >>> It's impossible to discuss this if I can't see any benefits because=20 >>> you didn't send any. What you sent were actions that can be done by=20 >>> the HA and I responded by saying that the same (or more) information = >>> is available to the MN. Therefore, if you think there are additional = >>> benefits to doing this in the HA then you need to tell us. >>>=20 >>> The bottom line is this: MIP works by letting the MN install=20 >>> bindings in the HA. If you want things to work in reverse you need=20 >>> to justify it. I can't see any justifications because you're not=20 >>> answering my questions on your scenarios. So, count me out on the = reverse direction :). >>>=20 >>>=20 >>> For >>>> me those I wrote about are benefits or potential benefits if you = want. >>>=20 >>> =3D> No you didn't. You wrote about things that can be done. Many=20 >>> things can be done by many entities, the question is why the HA and=20 >>> not the MN. >>>=20 >>>> One important thing in the discussion, although mentioned, but=20 >>>> forgotten later is that by making rules distribution one way only,=20 >>>> we do create limitation for benefits, or potential benefits if this = >>>> sounds better. >>>=20 >>> =3D> Well, we won't know what we're missing unless someone tells us. = >>> So far no one has mentioned the advantages of doing things in the=20 >>> reverse direction. >>> There is always something missing from a protocol (it's=20 >>> engineering), the question us whether it's significant or worth the = trouble. >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> /yuri >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Wednesday, June 03, 2009 10:10 AM >>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>>> flowbindings >>>>=20 >>>> Yuri, >>>>=20 >>>> I can't parse those events you refer to. I'l answer both emails = here. >>>> First the events you refer to: >>>>=20 >>>>>> - network condition towards CN(s) >>>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>>=20 >>>> =3D> What's the event? A change in those conditions? The MN knows = the=20 >>>> conditions of the e2e path as well as or better than the HA. What=20 >>>> is the benefit of having the HA send a hint and how reliable is=20 >>>> that hint anyway? >>>>=20 >>>>>> - Access provider (any access, not necessarily wireless) who=20 >>>>>> offeres HA services preferences change >>>>=20 >>>> =3D> Preferences change to what?? How does it know if such change=20 >>>> works for the MN at all? This is way too vague to be able to=20 >>>> discuss tradeoffs. >>>>=20 >>>>>> - Change of the access provider traffic to another backbone=20 >>>>>> provider due to the time of the day. >>>>>> - Traffic condition on HA interface, which accepts traffic from=20 >>>>>> MN if MN sends on some particular local interface >>>>=20 >>>> =3D> These are path changes. The HA has _no idea_ how such a change = >>>> affects each MN/CN combination and it's "hint" can cause more=20 >>>> problems than it solves. BTW, if you're talking about hints then=20 >>>> we're no longer talking about installing bindings in the MN. This=20 >>>> is a different topic. MIP doesn't transfer hints, it pretty much=20 >>>> sends "orders" >>>> from one end to another. >>>>=20 >>>> Now to the actions required by the MN: >>>>=20 >>>>> - reject, >>>>> - re-evaluate and reject >>>>> - re-evaluate and accept >>>>> - accept >>>>=20 >>>> =3D> First, by assuming that the MN can reject the "hint" as you = call=20 >>>> it you invalidate the whole argument for the HA to install rules. >>>> Rejecting a hint or even evaluating it means that the MN knows = more. >>>> Therefore, the HA's hint is a complete waste of bandwidth. >>>>=20 >>>> I'm still confused about the _benefits_ you see here. Or are you=20 >>>> assuming that the MN can't know those hints without the HA's=20 >>>> involvement? But if you're assuming that, then how can it reject=20 >>>> the hints? This whole proposal makes no sense to me at all. Not to=20 >>>> mention the complexity you implicitly assume in order to generate=20 >>>> those, hopefully reliable, hints. >>>>=20 >>>> Hesham >>>>=20 >>>>=20 >>>> On 3/06/09 5:23 PM, "Yuri Ismailov" = wrote: >>>>=20 >>>>> Hesham, >>>>>=20 >>>>> In my view these are events not scenarious. These events are known = >>>>> by HA but not MN. If HA acts upon events, given that it knows=20 >>>>> somewhat more about MN, not only IP addresses, it (HA) can=20 >>>>> generate new rules and send them as hint to MN. Back again, MN has = four options: >>>>>=20 >>>>> The benefit will be obviously that the new rules (if accepted) may = >>>>> llead to a better overall communication characteristics. >>>>>=20 >>>>> /yuri >>>>>=20 >>>>>=20 >>>>> =3D> I'm trying to understand what you mean above. These are all=20 >>>>> scenarios, the question is: What is the benefit for the HA to=20 >>>>> transfer rules? The HA will not know the path between the MN and=20 >>>>> CN more than either node does. So I don't understand what=20 >>>>> _benefits_ you see here. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>>=20 >>>>>> Pretty much sure that there are more examples and I encourage to=20 >>>>>> think about those not from MN point of view but rather from the=20 >>>>>> HA service provider. >>>>>>=20 >>>>>> /yuri >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>> pierrick.seite@orange-ftgroup.com >>>>>> Cc: mext@ietf.org >>>>>> Subject: Re: [MEXT] Important considerations for directionality=20 >>>>>> of flowbindings >>>>>>=20 >>>>>> Yuri, >>>>>>=20 >>>>>> It is just rules TRANSFER which is the matter of MIP. So where >>>>>>> is the logic when saying that MN to HA rules transfer is a=20 >>>>>>> practical engineering and HA to MN is an academic interest? >>>>>>=20 >>>>>> =3D> I think we've (I'm including myself) highlighted several=20 >>>>>> reasons for why it makes little sense to transfer rules from HA = to MN. >>>>>> Instead of rat-holing on theory Vs practice, you (or others=20 >>>>>> advocating the other direction) need to come up with reasons for=20 >>>>>> doing things this way. This way we can think like engineers about = >>>>>> tradeoffs. >>>>>> Absent that, I don't see any point in having theory Vs practice=20 >>>>>> high level discussions, which will lead nowhere. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Regards >>>>>>> Yuri >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>>> Subject: Re: [MEXT] Important considerations for directionality=20 >>>>>>> of flowbindings >>>>>>>=20 >>>>>>> Hi Pierrick, >>>>>>>=20 >>>>>>> On Jun 2, 2009, at 4:11 PM, = wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>> Please see inline comment. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Pierrick >>>>>>>>=20 >>>>>>>>> ________________________________________ >>>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De=20 >>>>>>>>> la part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 = =C0 : >>>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important=20 >>>>>>>>> considerations for directionality of flowbindings >>>>>>>>>=20 >>>>>>>>> Hesham, >>>>>>>>> This is nice story and makes some sense for the discssion,=20 >>>>>>>>> however some details are ommited. In your adventure with the=20 >>>>>>>>> helpdesk, it (the >>>>>>>>> helpdesk) is a third party service and thus your conclusions=20 >>>>>>>>> make sence. >>>>>>>>> Think of the situation when superior of a heldesk person will=20 >>>>>>>>> tell him/her to check access point in some room. Would it be=20 >>>>>>>>> the same reaction? I assume not. By that I mean that if, for=20 >>>>>>>>> example, I'll install home agent in my home network, I can=20 >>>>>>>>> make it know anything I want about MN, and more intresting is=20 >>>>>>>>> that how I will do it, does not require any standardization. >>>>>>>>> In other words, I'm superior of my HA. >>>>>>>>> This situation is not unthinkable, I personally believe that=20 >>>>>>>>> this is much more efficient way of using HA fnctionality as=20 >>>>>>>>> opposed to big service providers who will have to fight with=20 >>>>>>>>> scalability and performance. >>>>>>>>> However, one does not exclude another. >>>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The difference between policy and rules is not only a matter of = >>>>>>>> conversion. A policy, is a static, or quasi-static, set of=20 >>>>>>>> guidance for the MN (e.g use access network X for application=20 >>>>>>>> type >>>>>>>> A,...) while a rule update requires to be more dynamic. I mean: >>>>>>>> eventually a policy could be updated depending on network=20 >>>>>>>> condition (e.g if X overloaded, use access network Y for=20 >>>>>>>> application type A,...) but a rule reacts on local triggers = (e.g. >>>>>>>> modification of the radio link >>>>>>>> quality) with a shorter period of variation. So, IMHO, there is = >>>>>>>> no requirement for updating policy on a short period and=20 >>>>>>>> out-of-band mechanism can be used (e.g. IEEE 802.21 in push = mode,...). >>>>>>>=20 >>>>>>> Fully agree! >>>>>>> This is why I do not support the exchange of rules from the HA=20 >>>>>>> to the MN. >>>>>>> Policies may be exchanged from the HA to the MN, but MIP is=20 >>>>>>> definitely not the protocol to transport them. >>>>>>>=20 >>>>>>> Nicolas >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> My 2 cents... >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Is there any reason to restrict where such convertion takes = place? >>>>>>>>> True >>>>>>>>> that a HA does not know what is going on in the access=20 >>>>>>>>> network, on the other hand HA may know what is the network=20 >>>>>>>>> condition between HA and correspondent node. Either of this=20 >>>>>>>>> information is important, if not equally important. >>>>>>>>> It is not really difficult to let an MN to reject rules sent=20 >>>>>>>>> by HA, which in my view would be quite natural. This implies=20 >>>>>>>>> that HA must follow the rules installed by MN until explicit=20 >>>>>>>>> acceptance has been received from MN. >>>>>>>>> Such procedure is very similar to an MN beahviour when=20 >>>>>>>>> initiating new BU, where MN is not supposed to send any=20 >>>>>>>>> traffic before BU confirmation. >>>>>>>>> BTW, what is the numerical representation of "rough = consensus"? >>>>>>>>> I assume is when majority is for, is it so? >>>>>>>>> Yuri >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Hesham Soliman >>>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>>> To: mext >>>>>>>>> Subject: [MEXT] Important considerations for directionality of = >>>>>>>>> flow bindings >>>>>>>>>=20 >>>>>>>>> Hi all, >>>>>>>>>=20 >>>>>>>>> I've always been a fan of the IETF's tradition of rough=20 >>>>>>>>> concensus (as opposed to voting). To me, this implies that you = >>>>>>>>> need to get your point across and get other people to see that = >>>>>>>>> point of view. >>>>>>>>> As opposed to other organisations that require their members=20 >>>>>>>>> to vote and end up with rigid political positions. >>>>>>>>>=20 >>>>>>>>> The chairs asked us about the directionality question of the=20 >>>>>>>>> flows bindings. >>>>>>>>> On the charter question, I said that the charter doesn't need=20 >>>>>>>>> to mention how a solution should work, but rather what problem = >>>>>>>>> needs to be solved. >>>>>>>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>>>>>>> transferring rules "between" the MN and HA without mentioning=20 >>>>>>>>> directions. >>>>>>>>>=20 >>>>>>>>> Nevertheless, we still need to agree on identifying the=20 >>>>>>>>> requirement for the solution. And when it comes to this, I'm=20 >>>>>>>>> strongly against voting and I'll practice this by explaining=20 >>>>>>>>> in this email why I think rules can not be transferred from=20 >>>>>>>>> the HA to the MN and that the only direction that makes sense=20 >>>>>>>>> in MIP is >>>>>>>>> MN->HA. I'll deliberately ignore arguments like "some people=20 >>>>>>>>> MN->want >>>>>>>>> this" or "an SDO wants this". They fall under the "meaningless = words" >>>>>>>>> category and I'm incapable of discussing them because they=20 >>>>>>>>> come with voting attitudes. They all need to be justified if=20 >>>>>>>>> the WG wants to have a technical _discussion_. >>>>>>>>>=20 >>>>>>>>> Here are my reasons: >>>>>>>>>=20 >>>>>>>>> 1. The HA does not know whether a CoA is tied to a certain=20 >>>>>>>>> access technology. It is one thing for the HA to send a=20 >>>>>>>>> message saying "forward port 80 traffic on a wifi link" (a=20 >>>>>>>>> policy) and a completely different thing to say "forward port=20 >>>>>>>>> 80 traffic using CoA 3ffe::1" >>>>>>>>> (a rule). >>>>>>>>>=20 >>>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem now? >>>>>>>>> The problem is that the HA has no idea about dynamic changes=20 >>>>>>>>> on that wifi link. It doesn't know if it's congested, it=20 >>>>>>>>> doesn't know what application is using port 80 (it doesn't=20 >>>>>>>>> have to be web >>>>>>>>> traffic) or port 8000 for that matter and doesn't even know if = >>>>>>>>> the AP of that wifi link works at all. >>>>>>>>> Finally, it >>>>>>>>> doesn't know the user's policies or other admin policies for = that MN. >>>>>>>>> This type of information needs to be sent regularly because it = >>>>>>>>> changes all the time and requires serious cross layer=20 >>>>>>>>> integration including sometimes layer 8 integration! It's=20 >>>>>>>>> completely impractical. >>>>>>>>>=20 >>>>>>>>> 3. If the HA installed rules in the MN, what happens if the MN = >>>>>>>>> wants to change those rules. Say the wifi link went down, or=20 >>>>>>>>> the MN's wifi interface went down and it wants to move that=20 >>>>>>>>> traffic to another interface. Would the HA reject such move? >>>>>>>>> Does the MN have to justify to the HA why it needs to move=20 >>>>>>>>> traffic? Does that involve writing a letter perhaps? >>>>>>>>> If you say "well in that case, the HA should let the MN move=20 >>>>>>>>> the traffic" >>>>>>>>> then I'll ask you: what's the point of having the HA install=20 >>>>>>>>> this stuff if it has no authority and how does it know the=20 >>>>>>>>> reason for the MN's movement of the flow? >>>>>>>>> The way to control how users do things is to incentivise them=20 >>>>>>>>> with charging models and show them that things work better on=20 >>>>>>>>> certain technologies, not by installing rules that can't be=20 >>>>>>>>> followed. It's a broken mindset and we've known that it's=20 >>>>>>>>> broken for a long time. >>>>>>>>>=20 >>>>>>>>> 4. Some people mentioned that the HA should be able to revoke=20 >>>>>>>>> flows on the MN. I'm perfectly fine with that, just extend the = >>>>>>>>> binding revocation draft to handle flows and the rest is=20 >>>>>>>>> pretty straight forward. >>>>>>>>>=20 >>>>>>>>> Finally, I'll indulge in a true story that happened to me a=20 >>>>>>>>> few years ago when I found that my wifi link wasn't working in = >>>>>>>>> a hotel (no >>>>>>>>> radio) >>>>>>>>> and called the help desk. He insisted that the link was up an=20 >>>>>>>>> I insisted that it wasn't. When I asked him to tell me how he=20 >>>>>>>>> knows the link is up he said: I can ping the AP! Of course=20 >>>>>>>>> after another >>>>>>>>> 5 minutes of trying to convince him that pinging the AP=20 >>>>>>>>> doesn't mean the radio is actually working he sent someone to=20 >>>>>>>>> the hotel who in turn realised that the radio was not working. >>>>>>>>> For those people who want rules to be transferred from the HA=20 >>>>>>>>> to the MN, please think of your HA as this help desk person, = i.e. >>>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>>=20 >>>>>>>>> I hope this helps with the realisation that decisions can't be = >>>>>>>>> made here based on voting and that there is little merit to=20 >>>>>>>>> transferring rules from the HA to the MN. Policies can be=20 >>>>>>>>> transferred without any problems, but not rules. >>>>>>>>>=20 >>>>>>>>> Hesham >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> MEXT@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> MEXT@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From hesham@elevatemobile.com Thu Jun 4 07:39:05 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADFCA3A6C03 for ; Thu, 4 Jun 2009 07:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 MyvF1of4TqND for ; Thu, 4 Jun 2009 07:39:03 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id B557A3A6AF1 for ; Thu, 4 Jun 2009 07:38:34 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MCE5I-0004fp-DA; Fri, 05 Jun 2009 00:38:26 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Fri, 05 Jun 2009 00:38:17 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 14:39:05 -0000 Yuri, On 5/06/09 12:01 AM, "Yuri Ismailov" wrote: > Hesham, >=20 > I provided several scenarious which you said are invalid. This is where m= y > conclusion about standpoint comes from. > Whether you call hints policies or rules it does not change what informat= ion > can be provided by HA to MN. =3D> It changes the outcome for the work item we're discussing. I'm trying to come to a conclusion on this and there is a huge difference between transferring policies and installing flow bindings. > By sending rules HA does not install anything in MN. Likewise, MN does no= t > install rules in HA, it informs HA about currently made choices. As I rem= ember > rules will not be valid until proper Ack arrival, which for me means that= may > not be instantiated at all. > Niether rules nor polices are specific to MIP. As I wrote those can be > exchanged between hosts without any MIP implementation, just for access > selection purposes. Once it was decided to make it as part of MIP protoco= l, > I'm fine with that. Do not have any idea to discuss this, while personall= y > consider that the work on rules transfer can very well fit into the MEXT = group > but as a separate work item, but this is not the case now, so good enough= the > way it is. > And back again, it really gets repeated, so will lead to nowhere, you've = got > my arguments and tell that the information, which I'm talking about, is n= ot > usefull. What can I say more? I can put you on my position and start aski= ng > questions instead of answering. So, why it is not usefull? =3D> I explained why the specific information you mentioned was not useful/useable by the MN and this is what I referred to as unanswered. Because if you agree with my previous explanations then we don't need to discuss it further. If you disagree you certainly didn't tell me why. You have the charge of proof because you want to change the way MIP works currently, that's all I'm trying to say. Hesham=20 >=20 > /yuri >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Thursday, June 04, 2009 4:00 AM > To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of > flowbindings >=20 > Yuri, >=20 >=20 >=20 >> Missing is additional information which may be helpful in making >> better decision about interface selection by MN. >> Which information is that I wrote in my previous emails. Back to my >> examples (not all, do not want to repeat myself). If HA will have >> changed traffic shaping parameters on one of the incoming or outgoing >> interfaces, this will be important information for MN to know. >> We have agreed already that whether this information important or not, >> benfitial or not is a matter of standpoint. >=20 > =3D> I don't agree or like to think that it's a matter of standpoint. That'= s why > I asked you on every point you raised and compared this to the MN's knowl= edge > on e2e basis. Once we have "standpoints" then we're getting outside the > technical realm. The reason I don't think it's useful is that this inform= ation > cannot be used by the MN to select a CoA. I've already stated that before= and > you seemed to agree so I don't know why you repeat this as a reason for t= he HA > to install filters in the MN. Let me say it > again: There is no correlation between the routing on the HA's upstream > interfaces/ISP with the MN's selection of a CoA. >=20 >> I consider that knowing more is a benefit and will help to get better re= sult. >>=20 >> My point is still the same. I see the reverse rules sending as >> possibility to provide more information to the MN, thus make MN to get >> to better decision about interface selection for its flows. This point >> has not changed since the beginning of the discussion. >=20 > =3D> This is why we're not making progress IMO: >=20 > 1. The hints you refer to are not the same things as installing rules on = the > MN. Completely different information in fact. You've essentially proved t= hat > when you suggested that the MN can accept or reject them. So, let's not c= all > them rules. The more direct word for what you want to send is policies >=20 > 2. You didn't provide a valid scenario that we can discuss as to why it's > needed or how it could work. I've asked numerous questions in each email = that > were not answered (with the exception of the last email). It's not possib= le to > progress the discussion without answering each others' > questions. You can go back through the threads and verify this. >=20 > 3. If we're sending rules from the HA to the MN and the MN can reject tho= se > rules then the whole exercise is pointless. You really want to send polic= ies > not rules. I can imagine those policies being one of the inputs that the = MN > uses to make a decision. I still fail to see how anything happening on th= e > HA's upstream interfaces/ISP link can possibly influence the MN's decisio= n for > CoA selection. This is another unanswered question. >=20 > Hesham >=20 >>=20 >> /yuri >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Wednesday, June 03, 2009 4:09 PM >> To: Yuri Ismailov; Nicolas Montavont; >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of >> flowbindings >>=20 >>=20 >>=20 >>=20 >> On 3/06/09 10:47 PM, "Yuri Ismailov" wrote: >>=20 >>> Ok, see your point, however:-) >>>=20 >>> The major difference here is that your are talking about CoA >>> selection and I'm talking about interface selection. Quite a big differ= ence. >>=20 >> =3D> No, that's not the point really. The point is that there is no >> relationship between CoA/interface selection on the MN and the >> upstream ISP for the home network. >>=20 >>> I do not see any grounds for MN to select CoA, based on what? Prefix le= ngth? >>> While selection of an interface is based on expected characteristics >>> of the communication. Routes (up/down)link in my opinion do have >>> impact on the characteristics and this is exactly the information >>> missing in the MN when selecting interface. >>=20 >> =3D> There is nothing missing for the MN to make this selection. Please >> tell us specifically what is missing. You're changing points on me all t= he >> time now. >> Lets stick to one point at a time. What's missing? >>=20 >>>=20 >>> Whenever, MN decides to move a flow, the reason can be anything but >>> not which CoA it has configured on each interface. >>>=20 >>> Another thing is that MN will notice something e2e if and only if >>> such support is implemented in the MN. >>=20 >> =3D> Of course, so what? >>=20 >> Moreover, this notice can not be made at IP layer. >>> TCP fights alone with all problems and never tells to any other layer >>> what is going on. So what is left? Two options. Add this support to >>> operating system, which makes its (support) existence questionable, >>> or to applications, which is even more questionable. >>=20 >> =3D> It's interesting that you think it's questionable to add the >> support to the MN's OS but not questionable to add the support to the >> HA's OS, which will not lead to the same reliability as if it were >> done in the MN. It doesn't make sense to me. >>=20 >>>=20 >>>>>=20 >>>>> Well, that's debatable, but this is clearly not a reason to do anythi= ng. >>>>>=20 >>> Are you serious about that MIP may be broken because of that? >>=20 >> =3D> Yes! It's not designed to do what you want to do. Luckily, in this >> case what you want, IMO, is broken anyway so it's not a problem. >>=20 >> Hesham >>=20 >>>=20 >>> /yuri >>>=20 >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Wednesday, June 03, 2009 1:15 PM >>> To: Yuri Ismailov; Nicolas Montavont; >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of >>> flowbindings >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Still some answers, despite knowing that in your opinion they are >>>> not benefits. >>>>=20 >>>> First of all MIP will not be breaked if the rules will be sent in >>>> both directions. >>>=20 >>> =3D> Well, that's debatable, but this is clearly not a reason to do anyth= ing. >>>=20 >>>>=20 >>>> - Access provider preferences relate to the use of backbone >>>> provider, which may vary with the time of day. Changing backbone >>>> provider can make quite big difference for commnication between HA >>>> (if HA service is provided by the same access provider) and CN(s). >>>> The difference can be expressed in, let's say, number of hops, load, >>>> possibly something else. Such change is an event and may have an >>>> impact on the overall communication. This can be told directly to MN >>>> or HA. Direct communication to MN (if accepted as benefit:-)) in >>>> such case will need standardization. Communication of this >>>> information to HA does not (I consider this as a benefit). HA may >>>> act upon that event, and the rest you >>>> know: rules in reverse direction. >>>=20 >>> =3D> There is no need to _tell_ the MN anything. There are two issues her= e. >>> First, changing network conditions are best known e2e. So the MN will >>> know that anyway based on the traffic running between it and the CN. >>> The other issue is related to cost for certain times of day. This is >>> a routing issue in the HA and has nothing to do with which interface >>> the MN selects. The selected CoA has zero impact on the HA's upstream >>> selection. Completely irrelevant actually. >>> Of course, as far as cost on the visited link, the MN knows best. >>>=20 >>>>=20 >>>> - Access provider may set up different parameters for traffic >>>> shaping for each of HA interfaces. These preferences may vary >>>> independently of change of backbone provider but dependently on the ti= me of >>>> day. >>>> The rest you know, whether it changes somebodies opinion. >>>=20 >>> =3D> But again, this has zero effect on CoA selection. The two issues >>> are completely orthogonal. Selecting CoA1 or CoA2 has zero impact on >>> the HA's upstream route. >>>=20 >>>>=20 >>>> - I presume that in RO mode this is similar to HA mode, and I'm in >>>> when it comes to send rules in reverse direction between CN and MN. >>>> Benefits of doing that is that any change percieved by CN as >>>> important to react upon can be expressed in proposal of new rules. >>>> The sources causing changes may include but not limited to, are >>>> user, network managemnt events, application generated events, etc. >>>>=20 >>>> So feel free to consider this as benefits or not >>>=20 >>> =3D> You seem to think that there is a relationship between upstream >>> routing and CoA selection. That's not the case at all. These are two >>> different addresses from two different networks. >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> /yuri >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Wednesday, June 03, 2009 11:47 AM >>>> To: Yuri Ismailov; Nicolas Montavont; >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of >>>> flowbindings >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 3/06/09 7:33 PM, "Yuri Ismailov" wrote= : >>>>=20 >>>>> Hesham, >>>>>=20 >>>>> Whenever we talk about sending additional information, the "waste >>>>> of bandwidth" can be brought up. So I do not have an answer for >>>>> that besides speculations around it. >>>>=20 >>>> =3D> no no, I don't mean it literally, I mean that the message doesn't >>>> do anything, i.e. Has no benefit. >>>>=20 >>>>>=20 >>>>> Speaking about benefits, everybody who knows the area is capable of >>>>> turning things up side down. I assume it is subjective standpoint >>>>> of considering things as benefits or disadvantages and all is about >>>>> to agree or disagree. >>>>=20 >>>> =3D> That's fine, I'm asking for benefits in your opinion not someone el= se's. >>>> It's impossible to discuss this if I can't see any benefits because >>>> you didn't send any. What you sent were actions that can be done by >>>> the HA and I responded by saying that the same (or more) information >>>> is available to the MN. Therefore, if you think there are additional >>>> benefits to doing this in the HA then you need to tell us. >>>>=20 >>>> The bottom line is this: MIP works by letting the MN install >>>> bindings in the HA. If you want things to work in reverse you need >>>> to justify it. I can't see any justifications because you're not >>>> answering my questions on your scenarios. So, count me out on the reve= rse >>>> direction :). >>>>=20 >>>>=20 >>>> For >>>>> me those I wrote about are benefits or potential benefits if you want= . >>>>=20 >>>> =3D> No you didn't. You wrote about things that can be done. Many >>>> things can be done by many entities, the question is why the HA and >>>> not the MN. >>>>=20 >>>>> One important thing in the discussion, although mentioned, but >>>>> forgotten later is that by making rules distribution one way only, >>>>> we do create limitation for benefits, or potential benefits if this >>>>> sounds better. >>>>=20 >>>> =3D> Well, we won't know what we're missing unless someone tells us. >>>> So far no one has mentioned the advantages of doing things in the >>>> reverse direction. >>>> There is always something missing from a protocol (it's >>>> engineering), the question us whether it's significant or worth the >>>> trouble. >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> /yuri >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: Wednesday, June 03, 2009 10:10 AM >>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>> pierrick.seite@orange-ftgroup.com >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of >>>>> flowbindings >>>>>=20 >>>>> Yuri, >>>>>=20 >>>>> I can't parse those events you refer to. I'l answer both emails here. >>>>> First the events you refer to: >>>>>=20 >>>>>>> - network condition towards CN(s) >>>>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>>>=20 >>>>> =3D> What's the event? A change in those conditions? The MN knows the >>>>> conditions of the e2e path as well as or better than the HA. What >>>>> is the benefit of having the HA send a hint and how reliable is >>>>> that hint anyway? >>>>>=20 >>>>>>> - Access provider (any access, not necessarily wireless) who >>>>>>> offeres HA services preferences change >>>>>=20 >>>>> =3D> Preferences change to what?? How does it know if such change >>>>> works for the MN at all? This is way too vague to be able to >>>>> discuss tradeoffs. >>>>>=20 >>>>>>> - Change of the access provider traffic to another backbone >>>>>>> provider due to the time of the day. >>>>>>> - Traffic condition on HA interface, which accepts traffic from >>>>>>> MN if MN sends on some particular local interface >>>>>=20 >>>>> =3D> These are path changes. The HA has _no idea_ how such a change >>>>> affects each MN/CN combination and it's "hint" can cause more >>>>> problems than it solves. BTW, if you're talking about hints then >>>>> we're no longer talking about installing bindings in the MN. This >>>>> is a different topic. MIP doesn't transfer hints, it pretty much >>>>> sends "orders" >>>>> from one end to another. >>>>>=20 >>>>> Now to the actions required by the MN: >>>>>=20 >>>>>> - reject, >>>>>> - re-evaluate and reject >>>>>> - re-evaluate and accept >>>>>> - accept >>>>>=20 >>>>> =3D> First, by assuming that the MN can reject the "hint" as you call >>>>> it you invalidate the whole argument for the HA to install rules. >>>>> Rejecting a hint or even evaluating it means that the MN knows more. >>>>> Therefore, the HA's hint is a complete waste of bandwidth. >>>>>=20 >>>>> I'm still confused about the _benefits_ you see here. Or are you >>>>> assuming that the MN can't know those hints without the HA's >>>>> involvement? But if you're assuming that, then how can it reject >>>>> the hints? This whole proposal makes no sense to me at all. Not to >>>>> mention the complexity you implicitly assume in order to generate >>>>> those, hopefully reliable, hints. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>=20 >>>>> On 3/06/09 5:23 PM, "Yuri Ismailov" wrot= e: >>>>>=20 >>>>>> Hesham, >>>>>>=20 >>>>>> In my view these are events not scenarious. These events are known >>>>>> by HA but not MN. If HA acts upon events, given that it knows >>>>>> somewhat more about MN, not only IP addresses, it (HA) can >>>>>> generate new rules and send them as hint to MN. Back again, MN has f= our >>>>>> options: >>>>>>=20 >>>>>> The benefit will be obviously that the new rules (if accepted) may >>>>>> llead to a better overall communication characteristics. >>>>>>=20 >>>>>> /yuri >>>>>>=20 >>>>>>=20 >>>>>> =3D> I'm trying to understand what you mean above. These are all >>>>>> scenarios, the question is: What is the benefit for the HA to >>>>>> transfer rules? The HA will not know the path between the MN and >>>>>> CN more than either node does. So I don't understand what >>>>>> _benefits_ you see here. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>>=20 >>>>>>> Pretty much sure that there are more examples and I encourage to >>>>>>> think about those not from MN point of view but rather from the >>>>>>> HA service provider. >>>>>>>=20 >>>>>>> /yuri >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>> Cc: mext@ietf.org >>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>> of flowbindings >>>>>>>=20 >>>>>>> Yuri, >>>>>>>=20 >>>>>>> It is just rules TRANSFER which is the matter of MIP. So where >>>>>>>> is the logic when saying that MN to HA rules transfer is a >>>>>>>> practical engineering and HA to MN is an academic interest? >>>>>>>=20 >>>>>>> =3D> I think we've (I'm including myself) highlighted several >>>>>>> reasons for why it makes little sense to transfer rules from HA to = MN. >>>>>>> Instead of rat-holing on theory Vs practice, you (or others >>>>>>> advocating the other direction) need to come up with reasons for >>>>>>> doing things this way. This way we can think like engineers about >>>>>>> tradeoffs. >>>>>>> Absent that, I don't see any point in having theory Vs practice >>>>>>> high level discussions, which will lead nowhere. >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards >>>>>>>> Yuri >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>>> of flowbindings >>>>>>>>=20 >>>>>>>> Hi Pierrick, >>>>>>>>=20 >>>>>>>> On Jun 2, 2009, at 4:11 PM, wr= ote: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Hi all, >>>>>>>>>=20 >>>>>>>>> Please see inline comment. >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> Pierrick >>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De >>>>>>>>>> la part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 : >>>>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important >>>>>>>>>> considerations for directionality of flowbindings >>>>>>>>>>=20 >>>>>>>>>> Hesham, >>>>>>>>>> This is nice story and makes some sense for the discssion, >>>>>>>>>> however some details are ommited. In your adventure with the >>>>>>>>>> helpdesk, it (the >>>>>>>>>> helpdesk) is a third party service and thus your conclusions >>>>>>>>>> make sence. >>>>>>>>>> Think of the situation when superior of a heldesk person will >>>>>>>>>> tell him/her to check access point in some room. Would it be >>>>>>>>>> the same reaction? I assume not. By that I mean that if, for >>>>>>>>>> example, I'll install home agent in my home network, I can >>>>>>>>>> make it know anything I want about MN, and more intresting is >>>>>>>>>> that how I will do it, does not require any standardization. >>>>>>>>>> In other words, I'm superior of my HA. >>>>>>>>>> This situation is not unthinkable, I personally believe that >>>>>>>>>> this is much more efficient way of using HA fnctionality as >>>>>>>>>> opposed to big service providers who will have to fight with >>>>>>>>>> scalability and performance. >>>>>>>>>> However, one does not exclude another. >>>>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The difference between policy and rules is not only a matter of >>>>>>>>> conversion. A policy, is a static, or quasi-static, set of >>>>>>>>> guidance for the MN (e.g use access network X for application >>>>>>>>> type >>>>>>>>> A,...) while a rule update requires to be more dynamic. I mean: >>>>>>>>> eventually a policy could be updated depending on network >>>>>>>>> condition (e.g if X overloaded, use access network Y for >>>>>>>>> application type A,...) but a rule reacts on local triggers (e.g. >>>>>>>>> modification of the radio link >>>>>>>>> quality) with a shorter period of variation. So, IMHO, there is >>>>>>>>> no requirement for updating policy on a short period and >>>>>>>>> out-of-band mechanism can be used (e.g. IEEE 802.21 in push mode,= ...). >>>>>>>>=20 >>>>>>>> Fully agree! >>>>>>>> This is why I do not support the exchange of rules from the HA >>>>>>>> to the MN. >>>>>>>> Policies may be exchanged from the HA to the MN, but MIP is >>>>>>>> definitely not the protocol to transport them. >>>>>>>>=20 >>>>>>>> Nicolas >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> My 2 cents... >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Is there any reason to restrict where such convertion takes plac= e? >>>>>>>>>> True >>>>>>>>>> that a HA does not know what is going on in the access >>>>>>>>>> network, on the other hand HA may know what is the network >>>>>>>>>> condition between HA and correspondent node. Either of this >>>>>>>>>> information is important, if not equally important. >>>>>>>>>> It is not really difficult to let an MN to reject rules sent >>>>>>>>>> by HA, which in my view would be quite natural. This implies >>>>>>>>>> that HA must follow the rules installed by MN until explicit >>>>>>>>>> acceptance has been received from MN. >>>>>>>>>> Such procedure is very similar to an MN beahviour when >>>>>>>>>> initiating new BU, where MN is not supposed to send any >>>>>>>>>> traffic before BU confirmation. >>>>>>>>>> BTW, what is the numerical representation of "rough consensus"? >>>>>>>>>> I assume is when majority is for, is it so? >>>>>>>>>> Yuri >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>>>>>>>> Behalf Of Hesham Soliman >>>>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>>>> To: mext >>>>>>>>>> Subject: [MEXT] Important considerations for directionality of >>>>>>>>>> flow bindings >>>>>>>>>>=20 >>>>>>>>>> Hi all, >>>>>>>>>>=20 >>>>>>>>>> I've always been a fan of the IETF's tradition of rough >>>>>>>>>> concensus (as opposed to voting). To me, this implies that you >>>>>>>>>> need to get your point across and get other people to see that >>>>>>>>>> point of view. >>>>>>>>>> As opposed to other organisations that require their members >>>>>>>>>> to vote and end up with rigid political positions. >>>>>>>>>>=20 >>>>>>>>>> The chairs asked us about the directionality question of the >>>>>>>>>> flows bindings. >>>>>>>>>> On the charter question, I said that the charter doesn't need >>>>>>>>>> to mention how a solution should work, but rather what problem >>>>>>>>>> needs to be solved. >>>>>>>>>> Hence, as far as the charter is concerned, I'm fine with >>>>>>>>>> transferring rules "between" the MN and HA without mentioning >>>>>>>>>> directions. >>>>>>>>>>=20 >>>>>>>>>> Nevertheless, we still need to agree on identifying the >>>>>>>>>> requirement for the solution. And when it comes to this, I'm >>>>>>>>>> strongly against voting and I'll practice this by explaining >>>>>>>>>> in this email why I think rules can not be transferred from >>>>>>>>>> the HA to the MN and that the only direction that makes sense >>>>>>>>>> in MIP is >>>>>>>>>> MN->HA. I'll deliberately ignore arguments like "some people >>>>>>>>>> MN->want >>>>>>>>>> this" or "an SDO wants this". They fall under the "meaningless w= ords" >>>>>>>>>> category and I'm incapable of discussing them because they >>>>>>>>>> come with voting attitudes. They all need to be justified if >>>>>>>>>> the WG wants to have a technical _discussion_. >>>>>>>>>>=20 >>>>>>>>>> Here are my reasons: >>>>>>>>>>=20 >>>>>>>>>> 1. The HA does not know whether a CoA is tied to a certain >>>>>>>>>> access technology. It is one thing for the HA to send a >>>>>>>>>> message saying "forward port 80 traffic on a wifi link" (a >>>>>>>>>> policy) and a completely different thing to say "forward port >>>>>>>>>> 80 traffic using CoA 3ffe::1" >>>>>>>>>> (a rule). >>>>>>>>>>=20 >>>>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem now? >>>>>>>>>> The problem is that the HA has no idea about dynamic changes >>>>>>>>>> on that wifi link. It doesn't know if it's congested, it >>>>>>>>>> doesn't know what application is using port 80 (it doesn't >>>>>>>>>> have to be web >>>>>>>>>> traffic) or port 8000 for that matter and doesn't even know if >>>>>>>>>> the AP of that wifi link works at all. >>>>>>>>>> Finally, it >>>>>>>>>> doesn't know the user's policies or other admin policies for tha= t MN. >>>>>>>>>> This type of information needs to be sent regularly because it >>>>>>>>>> changes all the time and requires serious cross layer >>>>>>>>>> integration including sometimes layer 8 integration! It's >>>>>>>>>> completely impractical. >>>>>>>>>>=20 >>>>>>>>>> 3. If the HA installed rules in the MN, what happens if the MN >>>>>>>>>> wants to change those rules. Say the wifi link went down, or >>>>>>>>>> the MN's wifi interface went down and it wants to move that >>>>>>>>>> traffic to another interface. Would the HA reject such move? >>>>>>>>>> Does the MN have to justify to the HA why it needs to move >>>>>>>>>> traffic? Does that involve writing a letter perhaps? >>>>>>>>>> If you say "well in that case, the HA should let the MN move >>>>>>>>>> the traffic" >>>>>>>>>> then I'll ask you: what's the point of having the HA install >>>>>>>>>> this stuff if it has no authority and how does it know the >>>>>>>>>> reason for the MN's movement of the flow? >>>>>>>>>> The way to control how users do things is to incentivise them >>>>>>>>>> with charging models and show them that things work better on >>>>>>>>>> certain technologies, not by installing rules that can't be >>>>>>>>>> followed. It's a broken mindset and we've known that it's >>>>>>>>>> broken for a long time. >>>>>>>>>>=20 >>>>>>>>>> 4. Some people mentioned that the HA should be able to revoke >>>>>>>>>> flows on the MN. I'm perfectly fine with that, just extend the >>>>>>>>>> binding revocation draft to handle flows and the rest is >>>>>>>>>> pretty straight forward. >>>>>>>>>>=20 >>>>>>>>>> Finally, I'll indulge in a true story that happened to me a >>>>>>>>>> few years ago when I found that my wifi link wasn't working in >>>>>>>>>> a hotel (no >>>>>>>>>> radio) >>>>>>>>>> and called the help desk. He insisted that the link was up an >>>>>>>>>> I insisted that it wasn't. When I asked him to tell me how he >>>>>>>>>> knows the link is up he said: I can ping the AP! Of course >>>>>>>>>> after another >>>>>>>>>> 5 minutes of trying to convince him that pinging the AP >>>>>>>>>> doesn't mean the radio is actually working he sent someone to >>>>>>>>>> the hotel who in turn realised that the radio was not working. >>>>>>>>>> For those people who want rules to be transferred from the HA >>>>>>>>>> to the MN, please think of your HA as this help desk person, i.e= . >>>>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>>>=20 >>>>>>>>>> I hope this helps with the realisation that decisions can't be >>>>>>>>>> made here based on voting and that there is little merit to >>>>>>>>>> transferring rules from the HA to the MN. Policies can be >>>>>>>>>> transferred without any problems, but not rules. >>>>>>>>>>=20 >>>>>>>>>> Hesham >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> MEXT mailing list >>>>>>>>>> MEXT@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>> _______________________________________________ >>>>>>>>>> MEXT mailing list >>>>>>>>>> MEXT@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> MEXT@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From behcetsarikaya@yahoo.com Thu Jun 4 08:12:52 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C943A6C97 for ; Thu, 4 Jun 2009 08:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 SChQYTO-Zzx4 for ; Thu, 4 Jun 2009 08:12:50 -0700 (PDT) Received: from n9.bullet.re3.yahoo.com (n9.bullet.re3.yahoo.com [68.142.237.94]) by core3.amsl.com (Postfix) with SMTP id 7C2433A692C for ; Thu, 4 Jun 2009 08:12:49 -0700 (PDT) Received: from [68.142.230.29] by n9.bullet.re3.yahoo.com with NNFMP; 04 Jun 2009 15:12:49 -0000 Received: from [67.195.9.83] by t2.bullet.re2.yahoo.com with NNFMP; 04 Jun 2009 15:12:49 -0000 Received: from [67.195.9.100] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 04 Jun 2009 15:12:48 -0000 Received: from [127.0.0.1] by omp104.mail.gq1.yahoo.com with NNFMP; 04 Jun 2009 15:12:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 535032.10899.bm@omp104.mail.gq1.yahoo.com Received: (qmail 13032 invoked by uid 60001); 4 Jun 2009 15:12:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1244128368; bh=zL7Ju9HcBROKrYCQS5EC3FbMXuDiKERSTCOpWRhIu3I=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Dhz6oTlzlNBtZ8jV0mhjgTtJ4KMb6Xcj3t1J9xuYY+EzrE7NH+tupQIoKy4pk6vylUIuf2tDMG7qQAygiSOW5wNqhCDSCbD8JvK1mjj+jR6pK+TCZixKh6JfRr/e33s0k9w03bSpBQdFLDEqUklMU8QsMlbM9bsDyHuh5ehkkis= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zKiHtmfs/kX+6smfdOfL3jYNjn8ndSQD+BETFII8coSEReViTmT9jaenxFrQ/I/4qF/PQDfijEx4G/8pR2IKyYqPLOYp3nLyNSOCYGHEIUdC7CTp8egnu7ZBFALRUDiKYqCmfAA0cF+qPLQPUS6/8bTyMceVxA0GNg9vg/jBYFU=; Message-ID: <402522.12074.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: alitXakVM1nOfUkDBdXVc2B8Nqbf4sbSYzBD.HYGsCGKVsvLav9IqTDyi5t290J5OtNbVCwbOMOSE7eQpcMaKwDig8O54qmwOENft7iR5MOQ9K0JhwleWKmPstd_SD_9cg7V25Vw7B.nDkfL2GHtJ7p49qhBr7fOP_pL4FSfZgPMGJk3Hu9p5Lt1pgmHZGJNlRakMmdmgJv8GBNOg9FH8MR_gsi8h4Ho6s1qJ9ewmyKLUMZ04GhMHPJMRTpkwdzLPEZJDoqCJ9Aa8w49TFdok6hYGCZWhyq91cSi0EIkmya7epCfk04pp7uZey5x Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Thu, 04 Jun 2009 08:12:48 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: Date: Thu, 4 Jun 2009 08:12:48 -0700 (PDT) From: Behcet Sarikaya To: Hesham Soliman In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 15:12:52 -0000 Hesham, there is no change in your draft, I don't understand what you're re= ally talking about. You should sit back and enjoy.=0A=0ARegards,=0A=0ABehce= t=0A=0A=0A=0A----- Original Message ----=0AFrom: Hesham Soliman =0ATo: Yuri Ismailov ; Nicolas M= ontavont ; pierrick.seite@orange-ftgroup.com=0ACc: mext= @ietf.org=0ASent: Thursday, June 4, 2009 9:38:17 AM=0ASubject: Re: [MEXT] I= mportant considerations for directionality of flowbindings=0A=0AYuri,=0A=0A= =0AOn 5/06/09 12:01 AM, "Yuri Ismailov" wrote:= =0A=0A> Hesham,=0A> =0A> I provided several scenarious which you said are i= nvalid. This is where my=0A> conclusion about standpoint comes from.=0A> Wh= ether you call hints policies or rules it does not change what information= =0A> can be provided by HA to MN.=0A=0A=3D> It changes the outcome for the = work item we're discussing. I'm trying to=0Acome to a conclusion on this an= d there is a huge difference between=0Atransferring policies and installing= flow bindings.=0A=0A> By sending rules HA does not install anything in MN.= Likewise, MN does not=0A> install rules in HA, it informs HA about current= ly made choices. As I remember=0A> rules will not be valid until proper Ack= arrival, which for me means that may=0A> not be instantiated at all.=0A> N= iether rules nor polices are specific to MIP. As I wrote those can be=0A> e= xchanged between hosts without any MIP implementation, just for access=0A> = selection purposes. Once it was decided to make it as part of MIP protocol,= =0A> I'm fine with that. Do not have any idea to discuss this, while person= ally=0A> consider that the work on rules transfer can very well fit into th= e MEXT group=0A> but as a separate work item, but this is not the case now,= so good enough the=0A> way it is.=0A> And back again, it really gets repea= ted, so will lead to nowhere, you've got=0A> my arguments and tell that the= information, which I'm talking about, is not=0A> usefull. What can I say m= ore? I can put you on my position and start asking=0A> questions instead of= answering. So, why it is not usefull?=0A=0A=3D> I explained why the specif= ic information you mentioned was not=0Auseful/useable by the MN and this is= what I referred to as unanswered.=0ABecause if you agree with my previous = explanations then we don't need to=0Adiscuss it further. If you disagree yo= u certainly didn't tell me why. You=0Ahave the charge of proof because you = want to change the way MIP works=0Acurrently, that's all I'm trying to say.= =0A=0AHesham =0A=0A> =0A> /yuri=0A> =0A> =0A> -----Original Message-----=0A= > From: Hesham Soliman [mailto:hesham@elevatemobile.com]=0A> Sent: Thursday= , June 04, 2009 4:00 AM=0A> To: Yuri Ismailov; Nicolas Montavont; pierrick.= seite@orange-ftgroup.com=0A> Cc: mext@ietf.org=0A> Subject: Re: [MEXT] Impo= rtant considerations for directionality of=0A> flowbindings=0A> =0A> Yuri,= =0A> =0A> =0A> =0A>> Missing is additional information which may be helpful= in making=0A>> better decision about interface selection by MN.=0A>> Which= information is that I wrote in my previous emails. Back to my=0A>> example= s (not all, do not want to repeat myself). If HA will have=0A>> changed tra= ffic shaping parameters on one of the incoming or outgoing=0A>> interfaces,= this will be important information for MN to know.=0A>> We have agreed alr= eady that whether this information important or not,=0A>> benfitial or not = is a matter of standpoint.=0A> =0A> =3D> I don't agree or like to think tha= t it's a matter of standpoint. That's why=0A> I asked you on every point yo= u raised and compared this to the MN's knowledge=0A> on e2e basis. Once we = have "standpoints" then we're getting outside the=0A> technical realm. The = reason I don't think it's useful is that this information=0A> cannot be use= d by the MN to select a CoA. I've already stated that before and=0A> you se= emed to agree so I don't know why you repeat this as a reason for the HA=0A= > to install filters in the MN. Let me say it=0A> again: There is no correl= ation between the routing on the HA's upstream=0A> interfaces/ISP with the = MN's selection of a CoA.=0A> =0A>> I consider that knowing more is a benefi= t and will help to get better result.=0A>> =0A>> My point is still the same= .. I see the reverse rules sending as=0A>> possibility to provide more infor= mation to the MN, thus make MN to get=0A>> to better decision about interfa= ce selection for its flows. This point=0A>> has not changed since the begin= ning of the discussion.=0A> =0A> =3D> This is why we're not making progress= IMO:=0A> =0A> 1. The hints you refer to are not the same things as install= ing rules on the=0A> MN. Completely different information in fact. You've e= ssentially proved that=0A> when you suggested that the MN can accept or rej= ect them. So, let's not call=0A> them rules. The more direct word for what = you want to send is policies=0A> =0A> 2. You didn't provide a valid scenari= o that we can discuss as to why it's=0A> needed or how it could work. I've = asked numerous questions in each email that=0A> were not answered (with the= exception of the last email). It's not possible to=0A> progress the discus= sion without answering each others'=0A> questions. You can go back through = the threads and verify this.=0A> =0A> 3. If we're sending rules from the HA= to the MN and the MN can reject those=0A> rules then the whole exercise is= pointless. You really want to send policies=0A> not rules. I can imagine t= hose policies being one of the inputs that the MN=0A> uses to make a decisi= on. I still fail to see how anything happening on the=0A> HA's upstream int= erfaces/ISP link can possibly influence the MN's decision for=0A> CoA selec= tion. This is another unanswered question.=0A> =0A> Hesham=0A> =0A>> =0A>> = /yuri=0A>> =0A>> -----Original Message-----=0A>> From: Hesham Soliman [mail= to:hesham@elevatemobile.com]=0A>> Sent: Wednesday, June 03, 2009 4:09 PM=0A= >> To: Yuri Ismailov; Nicolas Montavont;=0A>> pierrick.seite@orange-ftgroup= ..com=0A>> Cc: mext@ietf.org=0A>> Subject: Re: [MEXT] Important consideratio= ns for directionality of=0A>> flowbindings=0A>> =0A>> =0A>> =0A>> =0A>> On = 3/06/09 10:47 PM, "Yuri Ismailov" wrote:=0A>> = =0A>>> Ok, see your point, however:-)=0A>>> =0A>>> The major difference her= e is that your are talking about CoA=0A>>> selection and I'm talking about = interface selection. Quite a big difference.=0A>> =0A>> =3D> No, that's not= the point really. The point is that there is no=0A>> relationship between = CoA/interface selection on the MN and the=0A>> upstream ISP for the home ne= twork.=0A>> =0A>>> I do not see any grounds for MN to select CoA, based on = what? Prefix length?=0A>>> While selection of an interface is based on expe= cted characteristics=0A>>> of the communication. Routes (up/down)link in my= opinion do have=0A>>> impact on the characteristics and this is exactly th= e information=0A>>> missing in the MN when selecting interface.=0A>> =0A>> = =3D> There is nothing missing for the MN to make this selection. Please=0A>= > tell us specifically what is missing. You're changing points on me all th= e=0A>> time now.=0A>> Lets stick to one point at a time. What's missing?=0A= >> =0A>>> =0A>>> Whenever, MN decides to move a flow, the reason can be any= thing but=0A>>> not which CoA it has configured on each interface.=0A>>> = =0A>>> Another thing is that MN will notice something e2e if and only if=0A= >>> such support is implemented in the MN.=0A>> =0A>> =3D> Of course, so wh= at?=0A>> =0A>>=A0 Moreover, this notice can not be made at IP layer.=0A>>> = TCP fights alone with all problems and never tells to any other layer=0A>>>= what is going on. So what is left? Two options. Add this support to=0A>>> = operating system, which makes its (support) existence questionable,=0A>>> o= r to applications, which is even more questionable.=0A>> =0A>> =3D> It's in= teresting that you think it's questionable to add the=0A>> support to the M= N's OS but not questionable to add the support to the=0A>> HA's OS, which w= ill not lead to the same reliability as if it were=0A>> done in the MN. It = doesn't make sense to me.=0A>> =0A>>> =0A>>>>> =0A>>>>> Well, that's debata= ble, but this is clearly not a reason to do anything.=0A>>>>> =0A>>> Are yo= u serious about that MIP may be broken because of that?=0A>> =0A>> =3D> Yes= ! It's not designed to do what you want to do. Luckily, in this=0A>> case w= hat you want, IMO, is broken anyway so it's not a problem.=0A>> =0A>> Hesha= m=0A>> =0A>>> =0A>>> /yuri=0A>>> =0A>>> =0A>>> -----Original Message-----= =0A>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com]=0A>>> Sent: W= ednesday, June 03, 2009 1:15 PM=0A>>> To: Yuri Ismailov; Nicolas Montavont;= =0A>>> pierrick.seite@orange-ftgroup.com=0A>>> Cc: mext@ietf.org=0A>>> Subj= ect: Re: [MEXT] Important considerations for directionality of=0A>>> flowbi= ndings=0A>>> =0A>>> =0A>>> =0A>>>> =0A>>>> Still some answers, despite know= ing that in your opinion they are=0A>>>> not benefits.=0A>>>> =0A>>>> First= of all MIP will not be breaked if the rules will be sent in=0A>>>> both di= rections.=0A>>> =0A>>> =3D> Well, that's debatable, but this is clearly not= a reason to do anything.=0A>>> =0A>>>> =0A>>>> - Access provider preferenc= es relate to the use of backbone=0A>>>> provider, which may vary with the t= ime of day. Changing backbone=0A>>>> provider can make quite big difference= for commnication between HA=0A>>>> (if HA service is provided by the same = access provider) and CN(s).=0A>>>> The difference can be expressed in, let'= s say, number of hops, load,=0A>>>> possibly something else. Such change is= an event and may have an=0A>>>> impact on the overall communication. This = can be told directly to MN=0A>>>> or HA. Direct communication to MN (if acc= epted as benefit:-)) in=0A>>>> such case will need standardization. Communi= cation of this=0A>>>> information to HA does not (I consider this as a bene= fit). HA may=0A>>>> act upon that event, and the rest you=0A>>>> know: rule= s in reverse direction.=0A>>> =0A>>> =3D> There is no need to _tell_ the MN= anything. There are two issues here.=0A>>> First, changing network conditi= ons are best known e2e. So the MN will=0A>>> know that anyway based on the = traffic running between it and the CN.=0A>>> The other issue is related to = cost for certain times of day. This is=0A>>> a routing issue in the HA and = has nothing to do with which interface=0A>>> the MN selects. The selected C= oA has zero impact on the HA's upstream=0A>>> selection. Completely irrelev= ant actually.=0A>>> Of course, as far as cost on the visited link, the MN k= nows best.=0A>>> =0A>>>> =0A>>>> - Access provider may set up different par= ameters for traffic=0A>>>> shaping for each of HA interfaces. These prefere= nces may vary=0A>>>> independently of change of backbone provider but depen= dently on the time of=0A>>>> day.=0A>>>> The rest you know, whether it chan= ges somebodies opinion.=0A>>> =0A>>> =3D> But again, this has zero effect o= n CoA selection. The two issues=0A>>> are completely orthogonal. Selecting = CoA1 or CoA2 has zero impact on=0A>>> the HA's upstream route.=0A>>> =0A>>>= > =0A>>>> - I presume that in RO mode this is similar to HA mode, and I'm i= n=0A>>>> when it comes to send rules in reverse direction between CN and MN= ..=0A>>>> Benefits of doing that is that any change percieved by CN as=0A>>>= > important to react upon can be expressed in proposal of new rules.=0A>>>>= The sources causing changes may include but not limited to, are=0A>>>> use= r, network managemnt events, application generated events, etc.=0A>>>> =0A>= >>> So feel free to consider this as benefits or not=0A>>> =0A>>> =3D> You = seem to think that there is a relationship between upstream=0A>>> routing a= nd CoA selection. That's not the case at all. These are two=0A>>> different= addresses from two different networks.=0A>>> =0A>>> Hesham=0A>>> =0A>>>> = =0A>>>> /yuri=0A>>>> =0A>>>> -----Original Message-----=0A>>>> From: Hesham= Soliman [mailto:hesham@elevatemobile.com]=0A>>>> Sent: Wednesday, June 03,= 2009 11:47 AM=0A>>>> To: Yuri Ismailov; Nicolas Montavont;=0A>>>> pierrick= ..seite@orange-ftgroup.com=0A>>>> Cc: mext@ietf.org=0A>>>> Subject: Re: [MEX= T] Important considerations for directionality of=0A>>>> flowbindings=0A>>>= > =0A>>>> =0A>>>> =0A>>>> =0A>>>> On 3/06/09 7:33 PM, "Yuri Ismailov" wrote:=0A>>>> =0A>>>>> Hesham,=0A>>>>> =0A>>>>> Whe= never we talk about sending additional information, the "waste=0A>>>>> of b= andwidth" can be brought up. So I do not have an answer for=0A>>>>> that be= sides speculations around it.=0A>>>> =0A>>>> =3D> no no, I don't mean it li= terally, I mean that the message doesn't=0A>>>> do anything, i.e. Has no be= nefit.=0A>>>> =0A>>>>> =0A>>>>> Speaking about benefits, everybody who know= s the area is capable of=0A>>>>> turning things up side down. I assume it i= s subjective standpoint=0A>>>>> of considering things as benefits or disadv= antages and all is about=0A>>>>> to agree or disagree.=0A>>>> =0A>>>> =3D> = That's fine, I'm asking for benefits in your opinion not someone else's.=0A= >>>> It's impossible to discuss this if I can't see any benefits because=0A= >>>> you didn't send any. What you sent were actions that can be done by=0A= >>>> the HA and I responded by saying that the same (or more) information= =0A>>>> is available to the MN. Therefore, if you think there are additiona= l=0A>>>> benefits to doing this in the HA then you need to tell us.=0A>>>> = =0A>>>> The bottom line is this: MIP works by letting the MN install=0A>>>>= bindings in the HA. If you want things to work in reverse you need=0A>>>> = to justify it. I can't see any justifications because you're not=0A>>>> ans= wering my questions on your scenarios. So, count me out on the reverse=0A>>= >> direction :).=0A>>>> =0A>>>> =0A>>>> For=0A>>>>> me those I wrote about = are benefits or potential benefits if you want.=0A>>>> =0A>>>> =3D> No you = didn't. You wrote about things that can be done. Many=0A>>>> things can be = done by many entities, the question is why the HA and=0A>>>> not the MN.=0A= >>>> =0A>>>>> One important thing in the discussion, although mentioned, bu= t=0A>>>>> forgotten later is that by making rules distribution one way only= ,=0A>>>>> we do create limitation for benefits, or potential benefits if th= is=0A>>>>> sounds better.=0A>>>> =0A>>>> =3D> Well, we won't know what we'r= e missing unless someone tells us.=0A>>>> So far no one has mentioned the a= dvantages of doing things in the=0A>>>> reverse direction.=0A>>>> There is = always something missing from a protocol (it's=0A>>>> engineering), the que= stion us whether it's significant or worth the=0A>>>> trouble.=0A>>>> =0A>>= >> Hesham=0A>>>> =0A>>>>> =0A>>>>> /yuri=0A>>>>> =0A>>>>> =0A>>>>> =0A>>>>>= -----Original Message-----=0A>>>>> From: Hesham Soliman [mailto:hesham@ele= vatemobile.com]=0A>>>>> Sent: Wednesday, June 03, 2009 10:10 AM=0A>>>>> To:= Yuri Ismailov; Nicolas Montavont;=0A>>>>> pierrick.seite@orange-ftgroup.co= m=0A>>>>> Cc: mext@ietf.org=0A>>>>> Subject: Re: [MEXT] Important considera= tions for directionality of=0A>>>>> flowbindings=0A>>>>> =0A>>>>> Yuri,=0A>= >>>> =0A>>>>> I can't parse those events you refer to. I'l answer both emai= ls here.=0A>>>>> First the events you refer to:=0A>>>>> =0A>>>>>>> - networ= k condition towards CN(s)=0A>>>>>>> - the sum of number of hops between MN = -> HA and HA -> CN=0A>>>>> =0A>>>>> =3D> What's the event? A change in thos= e conditions? The MN knows the=0A>>>>> conditions of the e2e path as well a= s or better than the HA. What=0A>>>>> is the benefit of having the HA send = a hint and how reliable is=0A>>>>> that hint anyway?=0A>>>>> =0A>>>>>>> - A= ccess provider (any access, not necessarily wireless) who=0A>>>>>>> offeres= HA services preferences change=0A>>>>> =0A>>>>> =3D> Preferences change to= what?? How does it know if such change=0A>>>>> works for the MN at all? Th= is is way too vague to be able to=0A>>>>> discuss tradeoffs.=0A>>>>> =0A>>>= >>>> - Change of the access provider traffic to another backbone=0A>>>>>>> = provider due to the time of the day.=0A>>>>>>> - Traffic condition on HA in= terface, which accepts traffic from=0A>>>>>>> MN if MN sends on some partic= ular local interface=0A>>>>> =0A>>>>> =3D> These are path changes. The HA h= as _no idea_ how such a change=0A>>>>> affects each MN/CN combination and i= t's "hint" can cause more=0A>>>>> problems than it solves. BTW, if you're t= alking about hints then=0A>>>>> we're no longer talking about installing bi= ndings in the MN. This=0A>>>>> is a different topic. MIP doesn't transfer h= ints, it pretty much=0A>>>>> sends "orders"=0A>>>>> from one end to another= ..=0A>>>>> =0A>>>>> Now to the actions required by the MN:=0A>>>>> =0A>>>>>>= - reject,=0A>>>>>> - re-evaluate and reject=0A>>>>>> - re-evaluate and acc= ept=0A>>>>>> - accept=0A>>>>> =0A>>>>> =3D> First, by assuming that the MN = can reject the "hint" as you call=0A>>>>> it you invalidate the whole argum= ent for the HA to install rules.=0A>>>>> Rejecting a hint or even evaluatin= g it means that the MN knows more.=0A>>>>> Therefore, the HA's hint is a co= mplete waste of bandwidth.=0A>>>>> =0A>>>>> I'm still confused about the _b= enefits_ you see here. Or are you=0A>>>>> assuming that the MN can't know t= hose hints without the HA's=0A>>>>> involvement? But if you're assuming tha= t, then how can it reject=0A>>>>> the hints? This whole proposal makes no s= ense to me at all. Not to=0A>>>>> mention the complexity you implicitly ass= ume in order to generate=0A>>>>> those, hopefully reliable, hints.=0A>>>>> = =0A>>>>> Hesham=0A>>>>> =0A>>>>> =0A>>>>> On 3/06/09 5:23 PM, "Yuri Ismailo= v" wrote:=0A>>>>> =0A>>>>>> Hesham,=0A>>>>>> = =0A>>>>>> In my view these are events not scenarious. These events are know= n=0A>>>>>> by HA but not MN. If HA acts upon events, given that it knows=0A= >>>>>> somewhat more about MN, not only IP addresses, it (HA) can=0A>>>>>> = generate new rules and send them as hint to MN. Back again, MN has four=0A>= >>>>> options:=0A>>>>>> =0A>>>>>> The benefit will be obviously that the ne= w rules (if accepted) may=0A>>>>>> llead to a better overall communication = characteristics.=0A>>>>>> =0A>>>>>> /yuri=0A>>>>>> =0A>>>>>> =0A>>>>>> =3D>= I'm trying to understand what you mean above. These are all=0A>>>>>> scena= rios, the question is: What is the benefit for the HA to=0A>>>>>> transfer = rules? The HA will not know the path between the MN and=0A>>>>>> CN more th= an either node does. So I don't understand what=0A>>>>>> _benefits_ you see= here.=0A>>>>>> =0A>>>>>> Hesham=0A>>>>>> =0A>>>>>>> =0A>>>>>>> Pretty much= sure that there are more examples and I encourage to=0A>>>>>>> think about= those not from MN point of view but rather from the=0A>>>>>>> HA service p= rovider.=0A>>>>>>> =0A>>>>>>> /yuri=0A>>>>>>> =0A>>>>>>> =0A>>>>>>> =0A>>>>= >>> =0A>>>>>>> -----Original Message-----=0A>>>>>>> From: Hesham Soliman [m= ailto:hesham@elevatemobile.com]=0A>>>>>>> Sent: Wednesday, June 03, 2009 8:= 41 AM=0A>>>>>>> To: Yuri Ismailov; Nicolas Montavont;=0A>>>>>>> pierrick.se= ite@orange-ftgroup.com=0A>>>>>>> Cc: mext@ietf.org=0A>>>>>>> Subject: Re: [= MEXT] Important considerations for directionality=0A>>>>>>> of flowbindings= =0A>>>>>>> =0A>>>>>>> Yuri,=0A>>>>>>> =0A>>>>>>>=A0 It is just rules TRANSF= ER which is the matter of MIP. So where=0A>>>>>>>> is the logic when saying= that MN to HA rules transfer is a=0A>>>>>>>> practical engineering and HA = to MN is an academic interest?=0A>>>>>>> =0A>>>>>>> =3D> I think we've (I'm= including myself) highlighted several=0A>>>>>>> reasons for why it makes l= ittle sense to transfer rules from HA to MN.=0A>>>>>>> Instead of rat-holin= g on theory Vs practice, you (or others=0A>>>>>>> advocating the other dire= ction) need to come up with reasons for=0A>>>>>>> doing things this way. Th= is way we can think like engineers about=0A>>>>>>> tradeoffs.=0A>>>>>>> Abs= ent that, I don't see any point in having theory Vs practice=0A>>>>>>> high= level discussions, which will lead nowhere.=0A>>>>>>> =0A>>>>>>> Hesham=0A= >>>>>>> =0A>>>>>>> =0A>>>>>>>> =0A>>>>>>>> Regards=0A>>>>>>>> Yuri=0A>>>>>>= >> =0A>>>>>>>> -----Original Message-----=0A>>>>>>>> From: Nicolas Montavon= t [mailto:ietf@montavont.net]=0A>>>>>>>> Sent: Tuesday, June 02, 2009 5:47 = PM=0A>>>>>>>> To: pierrick.seite@orange-ftgroup.com=0A>>>>>>>> Cc: Yuri Ism= ailov; hesham@elevatemobile.com; mext@ietf.org=0A>>>>>>>> Subject: Re: [MEX= T] Important considerations for directionality=0A>>>>>>>> of flowbindings= =0A>>>>>>>> =0A>>>>>>>> Hi Pierrick,=0A>>>>>>>> =0A>>>>>>>> On Jun 2, 2009,= at 4:11 PM, wrote:=0A>>>>>>>> =0A>>>>>= >>>> =0A>>>>>>>>> Hi all,=0A>>>>>>>>> =0A>>>>>>>>> Please see inline commen= t.=0A>>>>>>>>> =0A>>>>>>>>> Regards,=0A>>>>>>>>> Pierrick=0A>>>>>>>>> =0A>>= >>>>>>>> ________________________________________=0A>>>>>>>>>> De : mext-bo= unces@ietf.org [mailto:mext-bounces@ietf.org] De=0A>>>>>>>>>> la part de Yu= ri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 :=0A>>>>>>>>>> Hesham= Soliman; mext Objet : Re: [MEXT] Important=0A>>>>>>>>>> considerations for= directionality of flowbindings=0A>>>>>>>>>> =0A>>>>>>>>>> Hesham,=0A>>>>>>= >>>> This is nice story and makes some sense for the discssion,=0A>>>>>>>>>= > however some details are ommited. In your adventure with the=0A>>>>>>>>>>= helpdesk, it (the=0A>>>>>>>>>> helpdesk) is a third party service and thus= your conclusions=0A>>>>>>>>>> make sence.=0A>>>>>>>>>> Think of the situat= ion when superior of a heldesk person will=0A>>>>>>>>>> tell him/her to che= ck access point in some room. Would it be=0A>>>>>>>>>> the same reaction? I= assume not. By that I mean that if, for=0A>>>>>>>>>> example, I'll install= home agent in my home network, I can=0A>>>>>>>>>> make it know anything I = want about MN, and more intresting is=0A>>>>>>>>>> that how I will do it, d= oes not require any standardization.=0A>>>>>>>>>> In other words, I'm super= ior of my HA.=0A>>>>>>>>>> This situation is not unthinkable, I personally = believe that=0A>>>>>>>>>> this is much more efficient way of using HA fncti= onality as=0A>>>>>>>>>> opposed to big service providers who will have to f= ight with=0A>>>>>>>>>> scalability and performance.=0A>>>>>>>>>> However, o= ne does not exclude another.=0A>>>>>>>>>> Difference between policies and r= ules is a convertion step.=0A>>>>>>>>>> =0A>>>>>>>>>> =0A>>>>>>>>> =0A>>>>>= >>>> =0A>>>>>>>>> The difference between policy and rules is not only a mat= ter of=0A>>>>>>>>> conversion. A policy, is a static, or quasi-static, set = of=0A>>>>>>>>> guidance for the MN (e.g use access network X for applicatio= n=0A>>>>>>>>> type=0A>>>>>>>>> A,...) while a rule update requires to be mo= re dynamic. I mean:=0A>>>>>>>>> eventually a policy could be updated depend= ing on network=0A>>>>>>>>> condition (e.g if X overloaded, use access netwo= rk Y for=0A>>>>>>>>> application type A,...) but a rule reacts on local tri= ggers (e.g.=0A>>>>>>>>> modification of the radio link=0A>>>>>>>>> quality)= with a shorter period of variation. So, IMHO, there is=0A>>>>>>>>> no requ= irement for updating policy on a short period and=0A>>>>>>>>> out-of-band m= echanism can be used (e.g. IEEE 802.21 in push mode,...).=0A>>>>>>>> =0A>>>= >>>>> Fully agree!=0A>>>>>>>> This is why I do not support the exchange of = rules from the HA=0A>>>>>>>> to the MN.=0A>>>>>>>> Policies may be exchange= d from the HA to the MN, but MIP is=0A>>>>>>>> definitely not the protocol = to transport them.=0A>>>>>>>> =0A>>>>>>>> Nicolas=0A>>>>>>>> =0A>>>>>>>>> = =0A>>>>>>>>> =0A>>>>>>>>> My 2 cents...=0A>>>>>>>>> =0A>>>>>>>>>> =0A>>>>>>= >>>> Is there any reason to restrict where such convertion takes place?=0A>= >>>>>>>>> True=0A>>>>>>>>>> that a HA does not know what is going on in the= access=0A>>>>>>>>>> network, on the other hand HA may know what is the net= work=0A>>>>>>>>>> condition between HA and correspondent node. Either of th= is=0A>>>>>>>>>> information is important, if not equally important.=0A>>>>>= >>>>> It is not really difficult to let an MN to reject rules sent=0A>>>>>>= >>>> by HA, which in my view would be quite natural. This implies=0A>>>>>>>= >>> that HA must follow the rules installed by MN until explicit=0A>>>>>>>>= >> acceptance has been received from MN.=0A>>>>>>>>>> Such procedure is ver= y similar to an MN beahviour when=0A>>>>>>>>>> initiating new BU, where MN = is not supposed to send any=0A>>>>>>>>>> traffic before BU confirmation.=0A= >>>>>>>>>> BTW, what is the numerical representation of "rough consensus"?= =0A>>>>>>>>>> I assume is when majority is for, is it so?=0A>>>>>>>>>> Yuri= =0A>>>>>>>>>> =0A>>>>>>>>>> =0A>>>>>>>>>> -----Original Message-----=0A>>>>= >>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=0A>>>>= >>>>>> Behalf Of Hesham Soliman=0A>>>>>>>>>> Sent: Thursday, May 28, 2009 1= 2:07 PM=0A>>>>>>>>>> To: mext=0A>>>>>>>>>> Subject: [MEXT] Important consid= erations for directionality of=0A>>>>>>>>>> flow bindings=0A>>>>>>>>>> =0A>= >>>>>>>>> Hi all,=0A>>>>>>>>>> =0A>>>>>>>>>> I've always been a fan of the = IETF's tradition of rough=0A>>>>>>>>>> concensus (as opposed to voting). To= me, this implies that you=0A>>>>>>>>>> need to get your point across and g= et other people to see that=0A>>>>>>>>>> point of view.=0A>>>>>>>>>> As opp= osed to other organisations that require their members=0A>>>>>>>>>> to vote= and end up with rigid political positions.=0A>>>>>>>>>> =0A>>>>>>>>>> The = chairs asked us about the directionality question of the=0A>>>>>>>>>> flows= bindings.=0A>>>>>>>>>> On the charter question, I said that the charter do= esn't need=0A>>>>>>>>>> to mention how a solution should work, but rather w= hat problem=0A>>>>>>>>>> needs to be solved.=0A>>>>>>>>>> Hence, as far as = the charter is concerned, I'm fine with=0A>>>>>>>>>> transferring rules "be= tween" the MN and HA without mentioning=0A>>>>>>>>>> directions.=0A>>>>>>>>= >> =0A>>>>>>>>>> Nevertheless, we still need to agree on identifying the=0A= >>>>>>>>>> requirement for the solution. And when it comes to this, I'm=0A>= >>>>>>>>> strongly against voting and I'll practice this by explaining=0A>>= >>>>>>>> in this email why I think rules can not be transferred from=0A>>>>= >>>>>> the HA to the MN and that the only direction that makes sense=0A>>>>= >>>>>> in MIP is=0A>>>>>>>>>> MN->HA. I'll deliberately ignore arguments li= ke "some people=0A>>>>>>>>>> MN->want=0A>>>>>>>>>> this" or "an SDO wants t= his". They fall under the "meaningless words"=0A>>>>>>>>>> category and I'm= incapable of discussing them because they=0A>>>>>>>>>> come with voting at= titudes. They all need to be justified if=0A>>>>>>>>>> the WG wants to have= a technical _discussion_.=0A>>>>>>>>>> =0A>>>>>>>>>> Here are my reasons:= =0A>>>>>>>>>> =0A>>>>>>>>>> 1. The HA does not know whether a CoA is tied t= o a certain=0A>>>>>>>>>> access technology. It is one thing for the HA to s= end a=0A>>>>>>>>>> message saying "forward port 80 traffic on a wifi link" = (a=0A>>>>>>>>>> policy) and a completely different thing to say "forward po= rt=0A>>>>>>>>>> 80 traffic using CoA 3ffe::1"=0A>>>>>>>>>> (a rule).=0A>>>>= >>>>>> =0A>>>>>>>>>> 2. You might argue that the HA can be told by the MN t= hat=0A>>>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem no= w?=0A>>>>>>>>>> The problem is that the HA has no idea about dynamic change= s=0A>>>>>>>>>> on that wifi link. It doesn't know if it's congested, it=0A>= >>>>>>>>> doesn't know what application is using port 80 (it doesn't=0A>>>>= >>>>>> have to be web=0A>>>>>>>>>> traffic) or port 8000 for that matter an= d doesn't even know if=0A>>>>>>>>>> the AP of that wifi link works at all.= =0A>>>>>>>>>> Finally, it=0A>>>>>>>>>> doesn't know the user's policies or = other admin policies for that MN.=0A>>>>>>>>>> This type of information nee= ds to be sent regularly because it=0A>>>>>>>>>> changes all the time and re= quires serious cross layer=0A>>>>>>>>>> integration including sometimes lay= er 8 integration! It's=0A>>>>>>>>>> completely impractical.=0A>>>>>>>>>> = =0A>>>>>>>>>> 3. If the HA installed rules in the MN, what happens if the M= N=0A>>>>>>>>>> wants to change those rules. Say the wifi link went down, or= =0A>>>>>>>>>> the MN's wifi interface went down and it wants to move that= =0A>>>>>>>>>> traffic to another interface. Would the HA reject such move?= =0A>>>>>>>>>> Does the MN have to justify to the HA why it needs to move=0A= >>>>>>>>>> traffic? Does that involve writing a letter perhaps?=0A>>>>>>>>>= > If you say "well in that case, the HA should let the MN move=0A>>>>>>>>>>= the traffic"=0A>>>>>>>>>> then I'll ask you: what's the point of having th= e HA install=0A>>>>>>>>>> this stuff if it has no authority and how does it= know the=0A>>>>>>>>>> reason for the MN's movement of the flow?=0A>>>>>>>>= >> The way to control how users do things is to incentivise them=0A>>>>>>>>= >> with charging models and show them that things work better on=0A>>>>>>>>= >> certain technologies, not by installing rules that can't be=0A>>>>>>>>>>= followed. It's a broken mindset and we've known that it's=0A>>>>>>>>>> bro= ken for a long time.=0A>>>>>>>>>> =0A>>>>>>>>>> 4. Some people mentioned th= at the HA should be able to revoke=0A>>>>>>>>>> flows on the MN. I'm perfec= tly fine with that, just extend the=0A>>>>>>>>>> binding revocation draft t= o handle flows and the rest is=0A>>>>>>>>>> pretty straight forward.=0A>>>>= >>>>>> =0A>>>>>>>>>> Finally, I'll indulge in a true story that happened to= me a=0A>>>>>>>>>> few years ago when I found that my wifi link wasn't work= ing in=0A>>>>>>>>>> a hotel (no=0A>>>>>>>>>> radio)=0A>>>>>>>>>> and called= the help desk. He insisted that the link was up an=0A>>>>>>>>>> I insisted= that it wasn't. When I asked him to tell me how he=0A>>>>>>>>>> knows the = link is up he said: I can ping the AP! Of course=0A>>>>>>>>>> after another= =0A>>>>>>>>>> 5 minutes of trying to convince him that pinging the AP=0A>>>= >>>>>>> doesn't mean the radio is actually working he sent someone to=0A>>>= >>>>>>> the hotel who in turn realised that the radio was not working.=0A>>= >>>>>>>> For those people who want rules to be transferred from the HA=0A>>= >>>>>>>> to the MN, please think of your HA as this help desk person, i.e.= =0A>>>>>>>>>> it has no clue about what's happening at the other end.=0A>>>= >>>>>>> =0A>>>>>>>>>> I hope this helps with the realisation that decisions= can't be=0A>>>>>>>>>> made here based on voting and that there is little m= erit to=0A>>>>>>>>>> transferring rules from the HA to the MN. Policies can= be=0A>>>>>>>>>> transferred without any problems, but not rules.=0A>>>>>>>= >>> =0A>>>>>>>>>> Hesham=0A>>>>>>>>>> =0A>>>>>>>>>> =0A>>>>>>>>>> =0A>>>>>>= >>>> =0A>>>>>>>>>> =0A>>>>>>>>>> __________________________________________= _____=0A>>>>>>>>>> MEXT mailing list=0A>>>>>>>>>> MEXT@ietf.org=0A>>>>>>>>>= > https://www.ietf.org/mailman/listinfo/mext=0A>>>>>>>>>> _________________= ______________________________=0A>>>>>>>>>> MEXT mailing list=0A>>>>>>>>>> = MEXT@ietf.org=0A>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext=0A>>>= >>>>>> _______________________________________________=0A>>>>>>>>> MEXT mai= ling list=0A>>>>>>>>> MEXT@ietf.org=0A>>>>>>>>> https://www.ietf.org/mailma= n/listinfo/mext=0A>>>>>>>> =0A>>>>>>> =0A>>>>>>> =0A>>>>>> =0A>>>>>> =0A>>>= >> =0A>>>>> =0A>>>> =0A>>>> =0A>>> =0A>>> =0A>> =0A>> =0A> =0A> =0A=0A=0A__= _____________________________________________=0AMEXT mailing list=0AMEXT@ie= tf.org=0Ahttps://www.ietf.org/mailman/listinfo/mext=0A=0A=0A=0A From Basavaraj.Patil@nokia.com Thu Jun 4 13:58:30 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5EE3A6C7B for ; Thu, 4 Jun 2009 13:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] 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 tuFJUHLZVjuD for ; Thu, 4 Jun 2009 13:58:29 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id B80D93A68AD for ; Thu, 4 Jun 2009 13:58:28 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n54KwMfQ025132; Thu, 4 Jun 2009 23:58:23 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 23:58:25 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 23:58:24 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.108]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 4 Jun 2009 22:58:24 +0200 From: To: Date: Thu, 4 Jun 2009 22:58:33 +0200 Thread-Topic: Review of I-Ds draft-ietf-mext-firewall-vendor and draft-ietf-mext-firewall-admin Thread-Index: AcnlVziGcMjns67IIEO/VQFRZu1/3g== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jun 2009 20:58:24.0812 (UTC) FILETIME=[33A4BEC0:01C9E557] X-Nokia-AV: Clean Cc: Gabor.Bajko@nokia.com Subject: [MEXT] Review of I-Ds draft-ietf-mext-firewall-vendor and draft-ietf-mext-firewall-admin X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 20:58:30 -0000 My review comments about the following two I-Ds are below: 1. draft-ietf-mext-firewall-vendor-01 2. draft-ietf-mext-firewall-admin-01 The scope of the above I-Ds is restricted to Mobile IPv6 (RFC3775) only. It would be much more useful to specify the guidelines for firewall administrators and firewall implementers for the DSMIP6 protocol (http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-10.tx= t ) instead. DSMIP6 is much more practical in terms of real-world deployments and hence the WG is better off specifying the firewall considerations for DSMIP6. IMO it is time better spent and the document much more useful if it were to include the rules for the firewalls w.r.t DSMIP6. 1. draft-mext-firewall-vendor: - The intent of this I-D is to simply specify the implications of Mobile IPv6 signaling and user data on firewalls. The statement : "This document describes how to implement stateful packet filtering capability for MIPv6" needs to be modified accordingly. - The draft notes that signaling messages can be encrypted. However it does not capture the details of RFC4877 which explains the security for the signaling messages using ESP in transport and tunnel modes. The I-D needs to consider both these approaches in terms of the rules at the firewall. - The I-D does not consider the DHAAD signaling messages. For completeness it should be included. (Use of DHAAD is an ogoing discussion in the context of 3775bis). - The firewall rules in the case of DSMIP6 where the signaling and user data are encapsulated in IPv4 (and using UDP encapsulation in the case where the MN is behind a NAT) should be covered. The packet format as seen by the FW in various scenarios should be specified with the associated processing details. - The I-D does not mention any rules to allow IKEv2 signaling between the MN and HA. Would be good to specify these rules as well. It is however covered in the fw-admin I-D. - In the security considerations the I-D states: "In a typical enterprise environment, an administrator cannot distinguish Mobile IPv6 capable nodes from other nodes. In such a situation any node in the protected network may end up receiving unsolicited packets from outside the firewall." With the proper FW rules packets would only be forwarded to the HA. I dont see how this vulnerability would exist. Can you elaborate further on this? Would'nt there be another firewall between the HA and the hosts in the enterprise domain as well with enterprise specific rules? - It would be useful to have some figures which show the FWs that could be encountered between an MN-HA-CN. Rules which would apply to different FWs need to be specified explicitly. For example in the case of RO, the FW in front of an HA only needs to handle the RO signaling messages. But the FWs that are in the MN or CNs access networks may need to create pinholes for the RO traffic between the MN and CN. 2. draft-ietf-mext-firewall-admin-01 - Would be good to consider DSMIP6 as the baseline protocol for firewalls to deal with - Again, the I-D needs to consider the transport and tunnel mode ESP options for signaling - If the user data is also secured with IPsec, what are the rules at the FW? -Basavaraj From yuri.ismailov@ericsson.com Fri Jun 5 01:15:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD8C3A6A48 for ; Fri, 5 Jun 2009 01:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.082 X-Spam-Level: X-Spam-Status: No, score=-8.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 ytAFQb-1kzff for ; Fri, 5 Jun 2009 01:15:02 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2D0E93A68CD for ; Fri, 5 Jun 2009 01:15:00 -0700 (PDT) X-AuditID: c1b4fb3e-b7b2dae00000205f-b8-4a28d4064381 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id D6.30.08287.604D82A4; Fri, 5 Jun 2009 10:15:02 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jun 2009 10:14:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Jun 2009 10:14:31 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyA= References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 05 Jun 2009 08:14:33.0088 (UTC) FILETIME=[A8386800:01C9E5B5] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 08:15:04 -0000 Hesham, Still not clear for me why you call scenarious invalid? Some broadband providers (this is used in practice) have quota on the = amount of traffic sent by users. Once quota is exceeded provider = downgardes outgoing traffic from its network to 64Kbs (this figure is = the real example from real provider). Such combination of to paths, = where one is high speed, lets say 10 Mbs and another one is 64Kbs is = quite crusual to apps running on top of TCP. Not for all types of = traffic though. MN can not know about this situation. Nobody will send this information = to MN. That means that MN will choose its interfaces based on its = knowledge about 10Mbs link capabilities. Obtaining this isnformation = from HA is quite significant to make a better decision about choice of = interfaces for its flows. This is concrete example of what happens in the reality. Do you consider that this information will be useless for MN? /yuri -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Thursday, June 04, 2009 4:38 PM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings Yuri, On 5/06/09 12:01 AM, "Yuri Ismailov" wrote: > Hesham, >=20 > I provided several scenarious which you said are invalid. This is=20 > where my conclusion about standpoint comes from. > Whether you call hints policies or rules it does not change what=20 > information can be provided by HA to MN. =3D> It changes the outcome for the work item we're discussing. I'm = trying to come to a conclusion on this and there is a huge difference = between transferring policies and installing flow bindings. > By sending rules HA does not install anything in MN. Likewise, MN does = > not install rules in HA, it informs HA about currently made choices.=20 > As I remember rules will not be valid until proper Ack arrival, which=20 > for me means that may not be instantiated at all. > Niether rules nor polices are specific to MIP. As I wrote those can be = > exchanged between hosts without any MIP implementation, just for=20 > access selection purposes. Once it was decided to make it as part of=20 > MIP protocol, I'm fine with that. Do not have any idea to discuss=20 > this, while personally consider that the work on rules transfer can=20 > very well fit into the MEXT group but as a separate work item, but=20 > this is not the case now, so good enough the way it is. > And back again, it really gets repeated, so will lead to nowhere,=20 > you've got my arguments and tell that the information, which I'm=20 > talking about, is not usefull. What can I say more? I can put you on=20 > my position and start asking questions instead of answering. So, why = it is not usefull? =3D> I explained why the specific information you mentioned was not = useful/useable by the MN and this is what I referred to as unanswered. Because if you agree with my previous explanations then we don't need to = discuss it further. If you disagree you certainly didn't tell me why. = You have the charge of proof because you want to change the way MIP = works currently, that's all I'm trying to say. Hesham=20 >=20 > /yuri >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Thursday, June 04, 2009 4:00 AM > To: Yuri Ismailov; Nicolas Montavont;=20 > pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of=20 > flowbindings >=20 > Yuri, >=20 >=20 >=20 >> Missing is additional information which may be helpful in making=20 >> better decision about interface selection by MN. >> Which information is that I wrote in my previous emails. Back to my=20 >> examples (not all, do not want to repeat myself). If HA will have=20 >> changed traffic shaping parameters on one of the incoming or outgoing = >> interfaces, this will be important information for MN to know. >> We have agreed already that whether this information important or=20 >> not, benfitial or not is a matter of standpoint. >=20 > =3D> I don't agree or like to think that it's a matter of standpoint.=20 > That's why I asked you on every point you raised and compared this to=20 > the MN's knowledge on e2e basis. Once we have "standpoints" then we're = > getting outside the technical realm. The reason I don't think it's=20 > useful is that this information cannot be used by the MN to select a=20 > CoA. I've already stated that before and you seemed to agree so I=20 > don't know why you repeat this as a reason for the HA to install=20 > filters in the MN. Let me say it > again: There is no correlation between the routing on the HA's=20 > upstream interfaces/ISP with the MN's selection of a CoA. >=20 >> I consider that knowing more is a benefit and will help to get better = result. >>=20 >> My point is still the same. I see the reverse rules sending as=20 >> possibility to provide more information to the MN, thus make MN to=20 >> get to better decision about interface selection for its flows. This=20 >> point has not changed since the beginning of the discussion. >=20 > =3D> This is why we're not making progress IMO: >=20 > 1. The hints you refer to are not the same things as installing rules=20 > on the MN. Completely different information in fact. You've=20 > essentially proved that when you suggested that the MN can accept or=20 > reject them. So, let's not call them rules. The more direct word for=20 > what you want to send is policies >=20 > 2. You didn't provide a valid scenario that we can discuss as to why=20 > it's needed or how it could work. I've asked numerous questions in=20 > each email that were not answered (with the exception of the last=20 > email). It's not possible to progress the discussion without answering = each others' > questions. You can go back through the threads and verify this. >=20 > 3. If we're sending rules from the HA to the MN and the MN can reject=20 > those rules then the whole exercise is pointless. You really want to=20 > send policies not rules. I can imagine those policies being one of the = > inputs that the MN uses to make a decision. I still fail to see how=20 > anything happening on the HA's upstream interfaces/ISP link can=20 > possibly influence the MN's decision for CoA selection. This is = another unanswered question. >=20 > Hesham >=20 >>=20 >> /yuri >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Wednesday, June 03, 2009 4:09 PM >> To: Yuri Ismailov; Nicolas Montavont;=20 >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of=20 >> flowbindings >>=20 >>=20 >>=20 >>=20 >> On 3/06/09 10:47 PM, "Yuri Ismailov" = wrote: >>=20 >>> Ok, see your point, however:-) >>>=20 >>> The major difference here is that your are talking about CoA=20 >>> selection and I'm talking about interface selection. Quite a big = difference. >>=20 >> =3D> No, that's not the point really. The point is that there is no=20 >> relationship between CoA/interface selection on the MN and the=20 >> upstream ISP for the home network. >>=20 >>> I do not see any grounds for MN to select CoA, based on what? Prefix = length? >>> While selection of an interface is based on expected characteristics = >>> of the communication. Routes (up/down)link in my opinion do have=20 >>> impact on the characteristics and this is exactly the information=20 >>> missing in the MN when selecting interface. >>=20 >> =3D> There is nothing missing for the MN to make this selection. = Please=20 >> tell us specifically what is missing. You're changing points on me=20 >> all the time now. >> Lets stick to one point at a time. What's missing? >>=20 >>>=20 >>> Whenever, MN decides to move a flow, the reason can be anything but=20 >>> not which CoA it has configured on each interface. >>>=20 >>> Another thing is that MN will notice something e2e if and only if=20 >>> such support is implemented in the MN. >>=20 >> =3D> Of course, so what? >>=20 >> Moreover, this notice can not be made at IP layer. >>> TCP fights alone with all problems and never tells to any other=20 >>> layer what is going on. So what is left? Two options. Add this=20 >>> support to operating system, which makes its (support) existence=20 >>> questionable, or to applications, which is even more questionable. >>=20 >> =3D> It's interesting that you think it's questionable to add the=20 >> support to the MN's OS but not questionable to add the support to the = >> HA's OS, which will not lead to the same reliability as if it were=20 >> done in the MN. It doesn't make sense to me. >>=20 >>>=20 >>>>>=20 >>>>> Well, that's debatable, but this is clearly not a reason to do = anything. >>>>>=20 >>> Are you serious about that MIP may be broken because of that? >>=20 >> =3D> Yes! It's not designed to do what you want to do. Luckily, in = this=20 >> case what you want, IMO, is broken anyway so it's not a problem. >>=20 >> Hesham >>=20 >>>=20 >>> /yuri >>>=20 >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Wednesday, June 03, 2009 1:15 PM >>> To: Yuri Ismailov; Nicolas Montavont;=20 >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>> flowbindings >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Still some answers, despite knowing that in your opinion they are=20 >>>> not benefits. >>>>=20 >>>> First of all MIP will not be breaked if the rules will be sent in=20 >>>> both directions. >>>=20 >>> =3D> Well, that's debatable, but this is clearly not a reason to do = anything. >>>=20 >>>>=20 >>>> - Access provider preferences relate to the use of backbone=20 >>>> provider, which may vary with the time of day. Changing backbone=20 >>>> provider can make quite big difference for commnication between HA=20 >>>> (if HA service is provided by the same access provider) and CN(s). >>>> The difference can be expressed in, let's say, number of hops,=20 >>>> load, possibly something else. Such change is an event and may have = >>>> an impact on the overall communication. This can be told directly=20 >>>> to MN or HA. Direct communication to MN (if accepted as benefit:-)) = >>>> in such case will need standardization. Communication of this=20 >>>> information to HA does not (I consider this as a benefit). HA may=20 >>>> act upon that event, and the rest you >>>> know: rules in reverse direction. >>>=20 >>> =3D> There is no need to _tell_ the MN anything. There are two = issues here. >>> First, changing network conditions are best known e2e. So the MN=20 >>> will know that anyway based on the traffic running between it and = the CN. >>> The other issue is related to cost for certain times of day. This is = >>> a routing issue in the HA and has nothing to do with which interface = >>> the MN selects. The selected CoA has zero impact on the HA's=20 >>> upstream selection. Completely irrelevant actually. >>> Of course, as far as cost on the visited link, the MN knows best. >>>=20 >>>>=20 >>>> - Access provider may set up different parameters for traffic=20 >>>> shaping for each of HA interfaces. These preferences may vary=20 >>>> independently of change of backbone provider but dependently on the = >>>> time of day. >>>> The rest you know, whether it changes somebodies opinion. >>>=20 >>> =3D> But again, this has zero effect on CoA selection. The two = issues=20 >>> are completely orthogonal. Selecting CoA1 or CoA2 has zero impact on = >>> the HA's upstream route. >>>=20 >>>>=20 >>>> - I presume that in RO mode this is similar to HA mode, and I'm in=20 >>>> when it comes to send rules in reverse direction between CN and MN. >>>> Benefits of doing that is that any change percieved by CN as=20 >>>> important to react upon can be expressed in proposal of new rules. >>>> The sources causing changes may include but not limited to, are=20 >>>> user, network managemnt events, application generated events, etc. >>>>=20 >>>> So feel free to consider this as benefits or not >>>=20 >>> =3D> You seem to think that there is a relationship between upstream = >>> routing and CoA selection. That's not the case at all. These are two = >>> different addresses from two different networks. >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> /yuri >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Wednesday, June 03, 2009 11:47 AM >>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>>> flowbindings >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 3/06/09 7:33 PM, "Yuri Ismailov" = wrote: >>>>=20 >>>>> Hesham, >>>>>=20 >>>>> Whenever we talk about sending additional information, the "waste=20 >>>>> of bandwidth" can be brought up. So I do not have an answer for=20 >>>>> that besides speculations around it. >>>>=20 >>>> =3D> no no, I don't mean it literally, I mean that the message=20 >>>> doesn't do anything, i.e. Has no benefit. >>>>=20 >>>>>=20 >>>>> Speaking about benefits, everybody who knows the area is capable=20 >>>>> of turning things up side down. I assume it is subjective=20 >>>>> standpoint of considering things as benefits or disadvantages and=20 >>>>> all is about to agree or disagree. >>>>=20 >>>> =3D> That's fine, I'm asking for benefits in your opinion not = someone else's. >>>> It's impossible to discuss this if I can't see any benefits because = >>>> you didn't send any. What you sent were actions that can be done by = >>>> the HA and I responded by saying that the same (or more)=20 >>>> information is available to the MN. Therefore, if you think there=20 >>>> are additional benefits to doing this in the HA then you need to = tell us. >>>>=20 >>>> The bottom line is this: MIP works by letting the MN install=20 >>>> bindings in the HA. If you want things to work in reverse you need=20 >>>> to justify it. I can't see any justifications because you're not=20 >>>> answering my questions on your scenarios. So, count me out on the=20 >>>> reverse direction :). >>>>=20 >>>>=20 >>>> For >>>>> me those I wrote about are benefits or potential benefits if you = want. >>>>=20 >>>> =3D> No you didn't. You wrote about things that can be done. Many=20 >>>> things can be done by many entities, the question is why the HA and = >>>> not the MN. >>>>=20 >>>>> One important thing in the discussion, although mentioned, but=20 >>>>> forgotten later is that by making rules distribution one way only, = >>>>> we do create limitation for benefits, or potential benefits if=20 >>>>> this sounds better. >>>>=20 >>>> =3D> Well, we won't know what we're missing unless someone tells = us. >>>> So far no one has mentioned the advantages of doing things in the=20 >>>> reverse direction. >>>> There is always something missing from a protocol (it's=20 >>>> engineering), the question us whether it's significant or worth the = >>>> trouble. >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> /yuri >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: Wednesday, June 03, 2009 10:10 AM >>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>> pierrick.seite@orange-ftgroup.com >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of = >>>>> flowbindings >>>>>=20 >>>>> Yuri, >>>>>=20 >>>>> I can't parse those events you refer to. I'l answer both emails = here. >>>>> First the events you refer to: >>>>>=20 >>>>>>> - network condition towards CN(s) >>>>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>>>=20 >>>>> =3D> What's the event? A change in those conditions? The MN knows=20 >>>>> the conditions of the e2e path as well as or better than the HA.=20 >>>>> What is the benefit of having the HA send a hint and how reliable=20 >>>>> is that hint anyway? >>>>>=20 >>>>>>> - Access provider (any access, not necessarily wireless) who=20 >>>>>>> offeres HA services preferences change >>>>>=20 >>>>> =3D> Preferences change to what?? How does it know if such change=20 >>>>> works for the MN at all? This is way too vague to be able to=20 >>>>> discuss tradeoffs. >>>>>=20 >>>>>>> - Change of the access provider traffic to another backbone=20 >>>>>>> provider due to the time of the day. >>>>>>> - Traffic condition on HA interface, which accepts traffic from=20 >>>>>>> MN if MN sends on some particular local interface >>>>>=20 >>>>> =3D> These are path changes. The HA has _no idea_ how such a = change=20 >>>>> affects each MN/CN combination and it's "hint" can cause more=20 >>>>> problems than it solves. BTW, if you're talking about hints then=20 >>>>> we're no longer talking about installing bindings in the MN. This=20 >>>>> is a different topic. MIP doesn't transfer hints, it pretty much=20 >>>>> sends "orders" >>>>> from one end to another. >>>>>=20 >>>>> Now to the actions required by the MN: >>>>>=20 >>>>>> - reject, >>>>>> - re-evaluate and reject >>>>>> - re-evaluate and accept >>>>>> - accept >>>>>=20 >>>>> =3D> First, by assuming that the MN can reject the "hint" as you=20 >>>>> call it you invalidate the whole argument for the HA to install = rules. >>>>> Rejecting a hint or even evaluating it means that the MN knows = more. >>>>> Therefore, the HA's hint is a complete waste of bandwidth. >>>>>=20 >>>>> I'm still confused about the _benefits_ you see here. Or are you=20 >>>>> assuming that the MN can't know those hints without the HA's=20 >>>>> involvement? But if you're assuming that, then how can it reject=20 >>>>> the hints? This whole proposal makes no sense to me at all. Not to = >>>>> mention the complexity you implicitly assume in order to generate=20 >>>>> those, hopefully reliable, hints. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>=20 >>>>> On 3/06/09 5:23 PM, "Yuri Ismailov" = wrote: >>>>>=20 >>>>>> Hesham, >>>>>>=20 >>>>>> In my view these are events not scenarious. These events are=20 >>>>>> known by HA but not MN. If HA acts upon events, given that it=20 >>>>>> knows somewhat more about MN, not only IP addresses, it (HA) can=20 >>>>>> generate new rules and send them as hint to MN. Back again, MN=20 >>>>>> has four >>>>>> options: >>>>>>=20 >>>>>> The benefit will be obviously that the new rules (if accepted)=20 >>>>>> may llead to a better overall communication characteristics. >>>>>>=20 >>>>>> /yuri >>>>>>=20 >>>>>>=20 >>>>>> =3D> I'm trying to understand what you mean above. These are all=20 >>>>>> scenarios, the question is: What is the benefit for the HA to=20 >>>>>> transfer rules? The HA will not know the path between the MN and=20 >>>>>> CN more than either node does. So I don't understand what=20 >>>>>> _benefits_ you see here. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>>=20 >>>>>>> Pretty much sure that there are more examples and I encourage to = >>>>>>> think about those not from MN point of view but rather from the=20 >>>>>>> HA service provider. >>>>>>>=20 >>>>>>> /yuri >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>> Cc: mext@ietf.org >>>>>>> Subject: Re: [MEXT] Important considerations for directionality=20 >>>>>>> of flowbindings >>>>>>>=20 >>>>>>> Yuri, >>>>>>>=20 >>>>>>> It is just rules TRANSFER which is the matter of MIP. So where >>>>>>>> is the logic when saying that MN to HA rules transfer is a=20 >>>>>>>> practical engineering and HA to MN is an academic interest? >>>>>>>=20 >>>>>>> =3D> I think we've (I'm including myself) highlighted several=20 >>>>>>> reasons for why it makes little sense to transfer rules from HA = to MN. >>>>>>> Instead of rat-holing on theory Vs practice, you (or others=20 >>>>>>> advocating the other direction) need to come up with reasons for = >>>>>>> doing things this way. This way we can think like engineers=20 >>>>>>> about tradeoffs. >>>>>>> Absent that, I don't see any point in having theory Vs practice=20 >>>>>>> high level discussions, which will lead nowhere. >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards >>>>>>>> Yuri >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>>>> Subject: Re: [MEXT] Important considerations for directionality = >>>>>>>> of flowbindings >>>>>>>>=20 >>>>>>>> Hi Pierrick, >>>>>>>>=20 >>>>>>>> On Jun 2, 2009, at 4:11 PM, = wrote: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Hi all, >>>>>>>>>=20 >>>>>>>>> Please see inline comment. >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> Pierrick >>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De=20 >>>>>>>>>> la part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 = 09:35 =C0 : >>>>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important=20 >>>>>>>>>> considerations for directionality of flowbindings >>>>>>>>>>=20 >>>>>>>>>> Hesham, >>>>>>>>>> This is nice story and makes some sense for the discssion,=20 >>>>>>>>>> however some details are ommited. In your adventure with the=20 >>>>>>>>>> helpdesk, it (the >>>>>>>>>> helpdesk) is a third party service and thus your conclusions=20 >>>>>>>>>> make sence. >>>>>>>>>> Think of the situation when superior of a heldesk person will = >>>>>>>>>> tell him/her to check access point in some room. Would it be=20 >>>>>>>>>> the same reaction? I assume not. By that I mean that if, for=20 >>>>>>>>>> example, I'll install home agent in my home network, I can=20 >>>>>>>>>> make it know anything I want about MN, and more intresting is = >>>>>>>>>> that how I will do it, does not require any standardization. >>>>>>>>>> In other words, I'm superior of my HA. >>>>>>>>>> This situation is not unthinkable, I personally believe that=20 >>>>>>>>>> this is much more efficient way of using HA fnctionality as=20 >>>>>>>>>> opposed to big service providers who will have to fight with=20 >>>>>>>>>> scalability and performance. >>>>>>>>>> However, one does not exclude another. >>>>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The difference between policy and rules is not only a matter=20 >>>>>>>>> of conversion. A policy, is a static, or quasi-static, set of=20 >>>>>>>>> guidance for the MN (e.g use access network X for application=20 >>>>>>>>> type >>>>>>>>> A,...) while a rule update requires to be more dynamic. I = mean: >>>>>>>>> eventually a policy could be updated depending on network=20 >>>>>>>>> condition (e.g if X overloaded, use access network Y for=20 >>>>>>>>> application type A,...) but a rule reacts on local triggers = (e.g. >>>>>>>>> modification of the radio link >>>>>>>>> quality) with a shorter period of variation. So, IMHO, there=20 >>>>>>>>> is no requirement for updating policy on a short period and=20 >>>>>>>>> out-of-band mechanism can be used (e.g. IEEE 802.21 in push = mode,...). >>>>>>>>=20 >>>>>>>> Fully agree! >>>>>>>> This is why I do not support the exchange of rules from the HA=20 >>>>>>>> to the MN. >>>>>>>> Policies may be exchanged from the HA to the MN, but MIP is=20 >>>>>>>> definitely not the protocol to transport them. >>>>>>>>=20 >>>>>>>> Nicolas >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> My 2 cents... >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Is there any reason to restrict where such convertion takes = place? >>>>>>>>>> True >>>>>>>>>> that a HA does not know what is going on in the access=20 >>>>>>>>>> network, on the other hand HA may know what is the network=20 >>>>>>>>>> condition between HA and correspondent node. Either of this=20 >>>>>>>>>> information is important, if not equally important. >>>>>>>>>> It is not really difficult to let an MN to reject rules sent=20 >>>>>>>>>> by HA, which in my view would be quite natural. This implies=20 >>>>>>>>>> that HA must follow the rules installed by MN until explicit=20 >>>>>>>>>> acceptance has been received from MN. >>>>>>>>>> Such procedure is very similar to an MN beahviour when=20 >>>>>>>>>> initiating new BU, where MN is not supposed to send any=20 >>>>>>>>>> traffic before BU confirmation. >>>>>>>>>> BTW, what is the numerical representation of "rough = consensus"? >>>>>>>>>> I assume is when majority is for, is it so? >>>>>>>>>> Yuri >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Hesham Soliman >>>>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>>>> To: mext >>>>>>>>>> Subject: [MEXT] Important considerations for directionality=20 >>>>>>>>>> of flow bindings >>>>>>>>>>=20 >>>>>>>>>> Hi all, >>>>>>>>>>=20 >>>>>>>>>> I've always been a fan of the IETF's tradition of rough=20 >>>>>>>>>> concensus (as opposed to voting). To me, this implies that=20 >>>>>>>>>> you need to get your point across and get other people to see = >>>>>>>>>> that point of view. >>>>>>>>>> As opposed to other organisations that require their members=20 >>>>>>>>>> to vote and end up with rigid political positions. >>>>>>>>>>=20 >>>>>>>>>> The chairs asked us about the directionality question of the=20 >>>>>>>>>> flows bindings. >>>>>>>>>> On the charter question, I said that the charter doesn't need = >>>>>>>>>> to mention how a solution should work, but rather what=20 >>>>>>>>>> problem needs to be solved. >>>>>>>>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>>>>>>>> transferring rules "between" the MN and HA without mentioning = >>>>>>>>>> directions. >>>>>>>>>>=20 >>>>>>>>>> Nevertheless, we still need to agree on identifying the=20 >>>>>>>>>> requirement for the solution. And when it comes to this, I'm=20 >>>>>>>>>> strongly against voting and I'll practice this by explaining=20 >>>>>>>>>> in this email why I think rules can not be transferred from=20 >>>>>>>>>> the HA to the MN and that the only direction that makes sense = >>>>>>>>>> in MIP is >>>>>>>>>> MN->HA. I'll deliberately ignore arguments like "some people=20 >>>>>>>>>> MN->want >>>>>>>>>> this" or "an SDO wants this". They fall under the = "meaningless words" >>>>>>>>>> category and I'm incapable of discussing them because they=20 >>>>>>>>>> come with voting attitudes. They all need to be justified if=20 >>>>>>>>>> the WG wants to have a technical _discussion_. >>>>>>>>>>=20 >>>>>>>>>> Here are my reasons: >>>>>>>>>>=20 >>>>>>>>>> 1. The HA does not know whether a CoA is tied to a certain=20 >>>>>>>>>> access technology. It is one thing for the HA to send a=20 >>>>>>>>>> message saying "forward port 80 traffic on a wifi link" (a >>>>>>>>>> policy) and a completely different thing to say "forward port = >>>>>>>>>> 80 traffic using CoA 3ffe::1" >>>>>>>>>> (a rule). >>>>>>>>>>=20 >>>>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem now? >>>>>>>>>> The problem is that the HA has no idea about dynamic changes=20 >>>>>>>>>> on that wifi link. It doesn't know if it's congested, it=20 >>>>>>>>>> doesn't know what application is using port 80 (it doesn't=20 >>>>>>>>>> have to be web >>>>>>>>>> traffic) or port 8000 for that matter and doesn't even know=20 >>>>>>>>>> if the AP of that wifi link works at all. >>>>>>>>>> Finally, it >>>>>>>>>> doesn't know the user's policies or other admin policies for = that MN. >>>>>>>>>> This type of information needs to be sent regularly because=20 >>>>>>>>>> it changes all the time and requires serious cross layer=20 >>>>>>>>>> integration including sometimes layer 8 integration! It's=20 >>>>>>>>>> completely impractical. >>>>>>>>>>=20 >>>>>>>>>> 3. If the HA installed rules in the MN, what happens if the=20 >>>>>>>>>> MN wants to change those rules. Say the wifi link went down,=20 >>>>>>>>>> or the MN's wifi interface went down and it wants to move=20 >>>>>>>>>> that traffic to another interface. Would the HA reject such = move? >>>>>>>>>> Does the MN have to justify to the HA why it needs to move=20 >>>>>>>>>> traffic? Does that involve writing a letter perhaps? >>>>>>>>>> If you say "well in that case, the HA should let the MN move=20 >>>>>>>>>> the traffic" >>>>>>>>>> then I'll ask you: what's the point of having the HA install=20 >>>>>>>>>> this stuff if it has no authority and how does it know the=20 >>>>>>>>>> reason for the MN's movement of the flow? >>>>>>>>>> The way to control how users do things is to incentivise them = >>>>>>>>>> with charging models and show them that things work better on = >>>>>>>>>> certain technologies, not by installing rules that can't be=20 >>>>>>>>>> followed. It's a broken mindset and we've known that it's=20 >>>>>>>>>> broken for a long time. >>>>>>>>>>=20 >>>>>>>>>> 4. Some people mentioned that the HA should be able to revoke = >>>>>>>>>> flows on the MN. I'm perfectly fine with that, just extend=20 >>>>>>>>>> the binding revocation draft to handle flows and the rest is=20 >>>>>>>>>> pretty straight forward. >>>>>>>>>>=20 >>>>>>>>>> Finally, I'll indulge in a true story that happened to me a=20 >>>>>>>>>> few years ago when I found that my wifi link wasn't working=20 >>>>>>>>>> in a hotel (no >>>>>>>>>> radio) >>>>>>>>>> and called the help desk. He insisted that the link was up an = >>>>>>>>>> I insisted that it wasn't. When I asked him to tell me how he = >>>>>>>>>> knows the link is up he said: I can ping the AP! Of course=20 >>>>>>>>>> after another >>>>>>>>>> 5 minutes of trying to convince him that pinging the AP=20 >>>>>>>>>> doesn't mean the radio is actually working he sent someone to = >>>>>>>>>> the hotel who in turn realised that the radio was not = working. >>>>>>>>>> For those people who want rules to be transferred from the HA = >>>>>>>>>> to the MN, please think of your HA as this help desk person, = i.e. >>>>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>>>=20 >>>>>>>>>> I hope this helps with the realisation that decisions can't=20 >>>>>>>>>> be made here based on voting and that there is little merit=20 >>>>>>>>>> to transferring rules from the HA to the MN. Policies can be=20 >>>>>>>>>> transferred without any problems, but not rules. >>>>>>>>>>=20 >>>>>>>>>> Hesham >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> MEXT mailing list >>>>>>>>>> MEXT@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>> _______________________________________________ >>>>>>>>>> MEXT mailing list >>>>>>>>>> MEXT@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> MEXT@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From hesham@elevatemobile.com Fri Jun 5 02:37:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EA053A6947 for ; Fri, 5 Jun 2009 02:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 dotdlJwy6HG3 for ; Fri, 5 Jun 2009 02:37:26 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 3C3903A68EB for ; Fri, 5 Jun 2009 02:37:25 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MCVrO-0002U1-EF; Fri, 05 Jun 2009 19:37:16 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Fri, 05 Jun 2009 19:37:03 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 09:37:29 -0000 Yuri, > Still not clear for me why you call scenarious invalid? > Some broadband providers (this is used in practice) have quota on the amo= unt > of traffic sent by users. Once quota is exceeded provider downgardes outg= oing > traffic from its network to 64Kbs (this figure is the real example from r= eal > provider). Such combination of to paths, where one is high speed, lets sa= y 10 > Mbs and another one is 64Kbs is quite crusual to apps running on top of T= CP. > Not for all types of traffic though. =3D> Yes I know the scenario but I keep saying to you that the change in upstream routing in the HA has nothing to do with CoA selection by the MN i= n the visited network. If anything, you want the MN to change it's HoA depending on how the switch to another upstream ISP works. It's a completel= y irrelevant issue to this discussion. Do you agree? If not why not? I really want to see an answer to this point. >=20 > MN can not know about this situation. Nobody will send this information t= o MN. =3D> Yes and if it knows what will it do??? If you can answer that you will fix the deadlock we have. > That means that MN will choose its interfaces based on its knowledge abou= t > 10Mbs link capabilities. =3D> You're talking about two different things. The MN doesn't choose the HA'= s outgoing interface! What am I missing? Obtaining this isnformation from HA is quite > significant to make a better decision about choice of interfaces for its > flows. > This is concrete example of what happens in the reality. > Do you consider that this information will be useless for MN? =3D> Completely useless. Unless I'm missing something in your scenario. Just write down step by step what will happen and include messages. I don't see how this can possibly be relevant to the MN. Hesham Hesham >=20 > /yuri >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Thursday, June 04, 2009 4:38 PM > To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of > flowbindings >=20 > Yuri, >=20 >=20 > On 5/06/09 12:01 AM, "Yuri Ismailov" wrote: >=20 >> Hesham, >>=20 >> I provided several scenarious which you said are invalid. This is >> where my conclusion about standpoint comes from. >> Whether you call hints policies or rules it does not change what >> information can be provided by HA to MN. >=20 > =3D> It changes the outcome for the work item we're discussing. I'm trying = to > come to a conclusion on this and there is a huge difference between > transferring policies and installing flow bindings. >=20 >> By sending rules HA does not install anything in MN. Likewise, MN does >> not install rules in HA, it informs HA about currently made choices. >> As I remember rules will not be valid until proper Ack arrival, which >> for me means that may not be instantiated at all. >> Niether rules nor polices are specific to MIP. As I wrote those can be >> exchanged between hosts without any MIP implementation, just for >> access selection purposes. Once it was decided to make it as part of >> MIP protocol, I'm fine with that. Do not have any idea to discuss >> this, while personally consider that the work on rules transfer can >> very well fit into the MEXT group but as a separate work item, but >> this is not the case now, so good enough the way it is. >> And back again, it really gets repeated, so will lead to nowhere, >> you've got my arguments and tell that the information, which I'm >> talking about, is not usefull. What can I say more? I can put you on >> my position and start asking questions instead of answering. So, why it = is >> not usefull? >=20 > =3D> I explained why the specific information you mentioned was not > useful/useable by the MN and this is what I referred to as unanswered. > Because if you agree with my previous explanations then we don't need to > discuss it further. If you disagree you certainly didn't tell me why. You= have > the charge of proof because you want to change the way MIP works currentl= y, > that's all I'm trying to say. >=20 > Hesham=20 >=20 >>=20 >> /yuri >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Thursday, June 04, 2009 4:00 AM >> To: Yuri Ismailov; Nicolas Montavont; >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of >> flowbindings >>=20 >> Yuri, >>=20 >>=20 >>=20 >>> Missing is additional information which may be helpful in making >>> better decision about interface selection by MN. >>> Which information is that I wrote in my previous emails. Back to my >>> examples (not all, do not want to repeat myself). If HA will have >>> changed traffic shaping parameters on one of the incoming or outgoing >>> interfaces, this will be important information for MN to know. >>> We have agreed already that whether this information important or >>> not, benfitial or not is a matter of standpoint. >>=20 >> =3D> I don't agree or like to think that it's a matter of standpoint. >> That's why I asked you on every point you raised and compared this to >> the MN's knowledge on e2e basis. Once we have "standpoints" then we're >> getting outside the technical realm. The reason I don't think it's >> useful is that this information cannot be used by the MN to select a >> CoA. I've already stated that before and you seemed to agree so I >> don't know why you repeat this as a reason for the HA to install >> filters in the MN. Let me say it >> again: There is no correlation between the routing on the HA's >> upstream interfaces/ISP with the MN's selection of a CoA. >>=20 >>> I consider that knowing more is a benefit and will help to get better >>> result. >>>=20 >>> My point is still the same. I see the reverse rules sending as >>> possibility to provide more information to the MN, thus make MN to >>> get to better decision about interface selection for its flows. This >>> point has not changed since the beginning of the discussion. >>=20 >> =3D> This is why we're not making progress IMO: >>=20 >> 1. The hints you refer to are not the same things as installing rules >> on the MN. Completely different information in fact. You've >> essentially proved that when you suggested that the MN can accept or >> reject them. So, let's not call them rules. The more direct word for >> what you want to send is policies >>=20 >> 2. You didn't provide a valid scenario that we can discuss as to why >> it's needed or how it could work. I've asked numerous questions in >> each email that were not answered (with the exception of the last >> email). It's not possible to progress the discussion without answering e= ach >> others' >> questions. You can go back through the threads and verify this. >>=20 >> 3. If we're sending rules from the HA to the MN and the MN can reject >> those rules then the whole exercise is pointless. You really want to >> send policies not rules. I can imagine those policies being one of the >> inputs that the MN uses to make a decision. I still fail to see how >> anything happening on the HA's upstream interfaces/ISP link can >> possibly influence the MN's decision for CoA selection. This is another >> unanswered question. >>=20 >> Hesham >>=20 >>>=20 >>> /yuri >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Wednesday, June 03, 2009 4:09 PM >>> To: Yuri Ismailov; Nicolas Montavont; >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of >>> flowbindings >>>=20 >>>=20 >>>=20 >>>=20 >>> On 3/06/09 10:47 PM, "Yuri Ismailov" wrote= : >>>=20 >>>> Ok, see your point, however:-) >>>>=20 >>>> The major difference here is that your are talking about CoA >>>> selection and I'm talking about interface selection. Quite a big >>>> difference. >>>=20 >>> =3D> No, that's not the point really. The point is that there is no >>> relationship between CoA/interface selection on the MN and the >>> upstream ISP for the home network. >>>=20 >>>> I do not see any grounds for MN to select CoA, based on what? Prefix >>>> length? >>>> While selection of an interface is based on expected characteristics >>>> of the communication. Routes (up/down)link in my opinion do have >>>> impact on the characteristics and this is exactly the information >>>> missing in the MN when selecting interface. >>>=20 >>> =3D> There is nothing missing for the MN to make this selection. Please >>> tell us specifically what is missing. You're changing points on me >>> all the time now. >>> Lets stick to one point at a time. What's missing? >>>=20 >>>>=20 >>>> Whenever, MN decides to move a flow, the reason can be anything but >>>> not which CoA it has configured on each interface. >>>>=20 >>>> Another thing is that MN will notice something e2e if and only if >>>> such support is implemented in the MN. >>>=20 >>> =3D> Of course, so what? >>>=20 >>> Moreover, this notice can not be made at IP layer. >>>> TCP fights alone with all problems and never tells to any other >>>> layer what is going on. So what is left? Two options. Add this >>>> support to operating system, which makes its (support) existence >>>> questionable, or to applications, which is even more questionable. >>>=20 >>> =3D> It's interesting that you think it's questionable to add the >>> support to the MN's OS but not questionable to add the support to the >>> HA's OS, which will not lead to the same reliability as if it were >>> done in the MN. It doesn't make sense to me. >>>=20 >>>>=20 >>>>>>=20 >>>>>> Well, that's debatable, but this is clearly not a reason to do anyth= ing. >>>>>>=20 >>>> Are you serious about that MIP may be broken because of that? >>>=20 >>> =3D> Yes! It's not designed to do what you want to do. Luckily, in this >>> case what you want, IMO, is broken anyway so it's not a problem. >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> /yuri >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Wednesday, June 03, 2009 1:15 PM >>>> To: Yuri Ismailov; Nicolas Montavont; >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of >>>> flowbindings >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Still some answers, despite knowing that in your opinion they are >>>>> not benefits. >>>>>=20 >>>>> First of all MIP will not be breaked if the rules will be sent in >>>>> both directions. >>>>=20 >>>> =3D> Well, that's debatable, but this is clearly not a reason to do anyt= hing. >>>>=20 >>>>>=20 >>>>> - Access provider preferences relate to the use of backbone >>>>> provider, which may vary with the time of day. Changing backbone >>>>> provider can make quite big difference for commnication between HA >>>>> (if HA service is provided by the same access provider) and CN(s). >>>>> The difference can be expressed in, let's say, number of hops, >>>>> load, possibly something else. Such change is an event and may have >>>>> an impact on the overall communication. This can be told directly >>>>> to MN or HA. Direct communication to MN (if accepted as benefit:-)) >>>>> in such case will need standardization. Communication of this >>>>> information to HA does not (I consider this as a benefit). HA may >>>>> act upon that event, and the rest you >>>>> know: rules in reverse direction. >>>>=20 >>>> =3D> There is no need to _tell_ the MN anything. There are two issues he= re. >>>> First, changing network conditions are best known e2e. So the MN >>>> will know that anyway based on the traffic running between it and the = CN. >>>> The other issue is related to cost for certain times of day. This is >>>> a routing issue in the HA and has nothing to do with which interface >>>> the MN selects. The selected CoA has zero impact on the HA's >>>> upstream selection. Completely irrelevant actually. >>>> Of course, as far as cost on the visited link, the MN knows best. >>>>=20 >>>>>=20 >>>>> - Access provider may set up different parameters for traffic >>>>> shaping for each of HA interfaces. These preferences may vary >>>>> independently of change of backbone provider but dependently on the >>>>> time of day. >>>>> The rest you know, whether it changes somebodies opinion. >>>>=20 >>>> =3D> But again, this has zero effect on CoA selection. The two issues >>>> are completely orthogonal. Selecting CoA1 or CoA2 has zero impact on >>>> the HA's upstream route. >>>>=20 >>>>>=20 >>>>> - I presume that in RO mode this is similar to HA mode, and I'm in >>>>> when it comes to send rules in reverse direction between CN and MN. >>>>> Benefits of doing that is that any change percieved by CN as >>>>> important to react upon can be expressed in proposal of new rules. >>>>> The sources causing changes may include but not limited to, are >>>>> user, network managemnt events, application generated events, etc. >>>>>=20 >>>>> So feel free to consider this as benefits or not >>>>=20 >>>> =3D> You seem to think that there is a relationship between upstream >>>> routing and CoA selection. That's not the case at all. These are two >>>> different addresses from two different networks. >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> /yuri >>>>>=20 >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: Wednesday, June 03, 2009 11:47 AM >>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>> pierrick.seite@orange-ftgroup.com >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of >>>>> flowbindings >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 3/06/09 7:33 PM, "Yuri Ismailov" wrot= e: >>>>>=20 >>>>>> Hesham, >>>>>>=20 >>>>>> Whenever we talk about sending additional information, the "waste >>>>>> of bandwidth" can be brought up. So I do not have an answer for >>>>>> that besides speculations around it. >>>>>=20 >>>>> =3D> no no, I don't mean it literally, I mean that the message >>>>> doesn't do anything, i.e. Has no benefit. >>>>>=20 >>>>>>=20 >>>>>> Speaking about benefits, everybody who knows the area is capable >>>>>> of turning things up side down. I assume it is subjective >>>>>> standpoint of considering things as benefits or disadvantages and >>>>>> all is about to agree or disagree. >>>>>=20 >>>>> =3D> That's fine, I'm asking for benefits in your opinion not someone >>>>> else's. >>>>> It's impossible to discuss this if I can't see any benefits because >>>>> you didn't send any. What you sent were actions that can be done by >>>>> the HA and I responded by saying that the same (or more) >>>>> information is available to the MN. Therefore, if you think there >>>>> are additional benefits to doing this in the HA then you need to tell= us. >>>>>=20 >>>>> The bottom line is this: MIP works by letting the MN install >>>>> bindings in the HA. If you want things to work in reverse you need >>>>> to justify it. I can't see any justifications because you're not >>>>> answering my questions on your scenarios. So, count me out on the >>>>> reverse direction :). >>>>>=20 >>>>>=20 >>>>> For >>>>>> me those I wrote about are benefits or potential benefits if you wan= t. >>>>>=20 >>>>> =3D> No you didn't. You wrote about things that can be done. Many >>>>> things can be done by many entities, the question is why the HA and >>>>> not the MN. >>>>>=20 >>>>>> One important thing in the discussion, although mentioned, but >>>>>> forgotten later is that by making rules distribution one way only, >>>>>> we do create limitation for benefits, or potential benefits if >>>>>> this sounds better. >>>>>=20 >>>>> =3D> Well, we won't know what we're missing unless someone tells us. >>>>> So far no one has mentioned the advantages of doing things in the >>>>> reverse direction. >>>>> There is always something missing from a protocol (it's >>>>> engineering), the question us whether it's significant or worth the >>>>> trouble. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>>=20 >>>>>> /yuri >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>> Sent: Wednesday, June 03, 2009 10:10 AM >>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>> pierrick.seite@orange-ftgroup.com >>>>>> Cc: mext@ietf.org >>>>>> Subject: Re: [MEXT] Important considerations for directionality of >>>>>> flowbindings >>>>>>=20 >>>>>> Yuri, >>>>>>=20 >>>>>> I can't parse those events you refer to. I'l answer both emails here= . >>>>>> First the events you refer to: >>>>>>=20 >>>>>>>> - network condition towards CN(s) >>>>>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>>>>=20 >>>>>> =3D> What's the event? A change in those conditions? The MN knows >>>>>> the conditions of the e2e path as well as or better than the HA. >>>>>> What is the benefit of having the HA send a hint and how reliable >>>>>> is that hint anyway? >>>>>>=20 >>>>>>>> - Access provider (any access, not necessarily wireless) who >>>>>>>> offeres HA services preferences change >>>>>>=20 >>>>>> =3D> Preferences change to what?? How does it know if such change >>>>>> works for the MN at all? This is way too vague to be able to >>>>>> discuss tradeoffs. >>>>>>=20 >>>>>>>> - Change of the access provider traffic to another backbone >>>>>>>> provider due to the time of the day. >>>>>>>> - Traffic condition on HA interface, which accepts traffic from >>>>>>>> MN if MN sends on some particular local interface >>>>>>=20 >>>>>> =3D> These are path changes. The HA has _no idea_ how such a change >>>>>> affects each MN/CN combination and it's "hint" can cause more >>>>>> problems than it solves. BTW, if you're talking about hints then >>>>>> we're no longer talking about installing bindings in the MN. This >>>>>> is a different topic. MIP doesn't transfer hints, it pretty much >>>>>> sends "orders" >>>>>> from one end to another. >>>>>>=20 >>>>>> Now to the actions required by the MN: >>>>>>=20 >>>>>>> - reject, >>>>>>> - re-evaluate and reject >>>>>>> - re-evaluate and accept >>>>>>> - accept >>>>>>=20 >>>>>> =3D> First, by assuming that the MN can reject the "hint" as you >>>>>> call it you invalidate the whole argument for the HA to install rule= s. >>>>>> Rejecting a hint or even evaluating it means that the MN knows more. >>>>>> Therefore, the HA's hint is a complete waste of bandwidth. >>>>>>=20 >>>>>> I'm still confused about the _benefits_ you see here. Or are you >>>>>> assuming that the MN can't know those hints without the HA's >>>>>> involvement? But if you're assuming that, then how can it reject >>>>>> the hints? This whole proposal makes no sense to me at all. Not to >>>>>> mention the complexity you implicitly assume in order to generate >>>>>> those, hopefully reliable, hints. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>=20 >>>>>> On 3/06/09 5:23 PM, "Yuri Ismailov" wro= te: >>>>>>=20 >>>>>>> Hesham, >>>>>>>=20 >>>>>>> In my view these are events not scenarious. These events are >>>>>>> known by HA but not MN. If HA acts upon events, given that it >>>>>>> knows somewhat more about MN, not only IP addresses, it (HA) can >>>>>>> generate new rules and send them as hint to MN. Back again, MN >>>>>>> has four >>>>>>> options: >>>>>>>=20 >>>>>>> The benefit will be obviously that the new rules (if accepted) >>>>>>> may llead to a better overall communication characteristics. >>>>>>>=20 >>>>>>> /yuri >>>>>>>=20 >>>>>>>=20 >>>>>>> =3D> I'm trying to understand what you mean above. These are all >>>>>>> scenarios, the question is: What is the benefit for the HA to >>>>>>> transfer rules? The HA will not know the path between the MN and >>>>>>> CN more than either node does. So I don't understand what >>>>>>> _benefits_ you see here. >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Pretty much sure that there are more examples and I encourage to >>>>>>>> think about those not from MN point of view but rather from the >>>>>>>> HA service provider. >>>>>>>>=20 >>>>>>>> /yuri >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>> Cc: mext@ietf.org >>>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>>> of flowbindings >>>>>>>>=20 >>>>>>>> Yuri, >>>>>>>>=20 >>>>>>>> It is just rules TRANSFER which is the matter of MIP. So where >>>>>>>>> is the logic when saying that MN to HA rules transfer is a >>>>>>>>> practical engineering and HA to MN is an academic interest? >>>>>>>>=20 >>>>>>>> =3D> I think we've (I'm including myself) highlighted several >>>>>>>> reasons for why it makes little sense to transfer rules from HA to= MN. >>>>>>>> Instead of rat-holing on theory Vs practice, you (or others >>>>>>>> advocating the other direction) need to come up with reasons for >>>>>>>> doing things this way. This way we can think like engineers >>>>>>>> about tradeoffs. >>>>>>>> Absent that, I don't see any point in having theory Vs practice >>>>>>>> high level discussions, which will lead nowhere. >>>>>>>>=20 >>>>>>>> Hesham >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards >>>>>>>>> Yuri >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>>>> of flowbindings >>>>>>>>>=20 >>>>>>>>> Hi Pierrick, >>>>>>>>>=20 >>>>>>>>> On Jun 2, 2009, at 4:11 PM, w= rote: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Hi all, >>>>>>>>>>=20 >>>>>>>>>> Please see inline comment. >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>> Pierrick >>>>>>>>>>=20 >>>>>>>>>>> ________________________________________ >>>>>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De >>>>>>>>>>> la part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 = : >>>>>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important >>>>>>>>>>> considerations for directionality of flowbindings >>>>>>>>>>>=20 >>>>>>>>>>> Hesham, >>>>>>>>>>> This is nice story and makes some sense for the discssion, >>>>>>>>>>> however some details are ommited. In your adventure with the >>>>>>>>>>> helpdesk, it (the >>>>>>>>>>> helpdesk) is a third party service and thus your conclusions >>>>>>>>>>> make sence. >>>>>>>>>>> Think of the situation when superior of a heldesk person will >>>>>>>>>>> tell him/her to check access point in some room. Would it be >>>>>>>>>>> the same reaction? I assume not. By that I mean that if, for >>>>>>>>>>> example, I'll install home agent in my home network, I can >>>>>>>>>>> make it know anything I want about MN, and more intresting is >>>>>>>>>>> that how I will do it, does not require any standardization. >>>>>>>>>>> In other words, I'm superior of my HA. >>>>>>>>>>> This situation is not unthinkable, I personally believe that >>>>>>>>>>> this is much more efficient way of using HA fnctionality as >>>>>>>>>>> opposed to big service providers who will have to fight with >>>>>>>>>>> scalability and performance. >>>>>>>>>>> However, one does not exclude another. >>>>>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> The difference between policy and rules is not only a matter >>>>>>>>>> of conversion. A policy, is a static, or quasi-static, set of >>>>>>>>>> guidance for the MN (e.g use access network X for application >>>>>>>>>> type >>>>>>>>>> A,...) while a rule update requires to be more dynamic. I mean: >>>>>>>>>> eventually a policy could be updated depending on network >>>>>>>>>> condition (e.g if X overloaded, use access network Y for >>>>>>>>>> application type A,...) but a rule reacts on local triggers (e.g= . >>>>>>>>>> modification of the radio link >>>>>>>>>> quality) with a shorter period of variation. So, IMHO, there >>>>>>>>>> is no requirement for updating policy on a short period and >>>>>>>>>> out-of-band mechanism can be used (e.g. IEEE 802.21 in push >>>>>>>>>> mode,...). >>>>>>>>>=20 >>>>>>>>> Fully agree! >>>>>>>>> This is why I do not support the exchange of rules from the HA >>>>>>>>> to the MN. >>>>>>>>> Policies may be exchanged from the HA to the MN, but MIP is >>>>>>>>> definitely not the protocol to transport them. >>>>>>>>>=20 >>>>>>>>> Nicolas >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> My 2 cents... >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Is there any reason to restrict where such convertion takes pla= ce? >>>>>>>>>>> True >>>>>>>>>>> that a HA does not know what is going on in the access >>>>>>>>>>> network, on the other hand HA may know what is the network >>>>>>>>>>> condition between HA and correspondent node. Either of this >>>>>>>>>>> information is important, if not equally important. >>>>>>>>>>> It is not really difficult to let an MN to reject rules sent >>>>>>>>>>> by HA, which in my view would be quite natural. This implies >>>>>>>>>>> that HA must follow the rules installed by MN until explicit >>>>>>>>>>> acceptance has been received from MN. >>>>>>>>>>> Such procedure is very similar to an MN beahviour when >>>>>>>>>>> initiating new BU, where MN is not supposed to send any >>>>>>>>>>> traffic before BU confirmation. >>>>>>>>>>> BTW, what is the numerical representation of "rough consensus"? >>>>>>>>>>> I assume is when majority is for, is it so? >>>>>>>>>>> Yuri >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>>>>>>>>> Behalf Of Hesham Soliman >>>>>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>>>>> To: mext >>>>>>>>>>> Subject: [MEXT] Important considerations for directionality >>>>>>>>>>> of flow bindings >>>>>>>>>>>=20 >>>>>>>>>>> Hi all, >>>>>>>>>>>=20 >>>>>>>>>>> I've always been a fan of the IETF's tradition of rough >>>>>>>>>>> concensus (as opposed to voting). To me, this implies that >>>>>>>>>>> you need to get your point across and get other people to see >>>>>>>>>>> that point of view. >>>>>>>>>>> As opposed to other organisations that require their members >>>>>>>>>>> to vote and end up with rigid political positions. >>>>>>>>>>>=20 >>>>>>>>>>> The chairs asked us about the directionality question of the >>>>>>>>>>> flows bindings. >>>>>>>>>>> On the charter question, I said that the charter doesn't need >>>>>>>>>>> to mention how a solution should work, but rather what >>>>>>>>>>> problem needs to be solved. >>>>>>>>>>> Hence, as far as the charter is concerned, I'm fine with >>>>>>>>>>> transferring rules "between" the MN and HA without mentioning >>>>>>>>>>> directions. >>>>>>>>>>>=20 >>>>>>>>>>> Nevertheless, we still need to agree on identifying the >>>>>>>>>>> requirement for the solution. And when it comes to this, I'm >>>>>>>>>>> strongly against voting and I'll practice this by explaining >>>>>>>>>>> in this email why I think rules can not be transferred from >>>>>>>>>>> the HA to the MN and that the only direction that makes sense >>>>>>>>>>> in MIP is >>>>>>>>>>> MN->HA. I'll deliberately ignore arguments like "some people >>>>>>>>>>> MN->want >>>>>>>>>>> this" or "an SDO wants this". They fall under the "meaningless >>>>>>>>>>> words" >>>>>>>>>>> category and I'm incapable of discussing them because they >>>>>>>>>>> come with voting attitudes. They all need to be justified if >>>>>>>>>>> the WG wants to have a technical _discussion_. >>>>>>>>>>>=20 >>>>>>>>>>> Here are my reasons: >>>>>>>>>>>=20 >>>>>>>>>>> 1. The HA does not know whether a CoA is tied to a certain >>>>>>>>>>> access technology. It is one thing for the HA to send a >>>>>>>>>>> message saying "forward port 80 traffic on a wifi link" (a >>>>>>>>>>> policy) and a completely different thing to say "forward port >>>>>>>>>>> 80 traffic using CoA 3ffe::1" >>>>>>>>>>> (a rule). >>>>>>>>>>>=20 >>>>>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem now? >>>>>>>>>>> The problem is that the HA has no idea about dynamic changes >>>>>>>>>>> on that wifi link. It doesn't know if it's congested, it >>>>>>>>>>> doesn't know what application is using port 80 (it doesn't >>>>>>>>>>> have to be web >>>>>>>>>>> traffic) or port 8000 for that matter and doesn't even know >>>>>>>>>>> if the AP of that wifi link works at all. >>>>>>>>>>> Finally, it >>>>>>>>>>> doesn't know the user's policies or other admin policies for th= at >>>>>>>>>>> MN. >>>>>>>>>>> This type of information needs to be sent regularly because >>>>>>>>>>> it changes all the time and requires serious cross layer >>>>>>>>>>> integration including sometimes layer 8 integration! It's >>>>>>>>>>> completely impractical. >>>>>>>>>>>=20 >>>>>>>>>>> 3. If the HA installed rules in the MN, what happens if the >>>>>>>>>>> MN wants to change those rules. Say the wifi link went down, >>>>>>>>>>> or the MN's wifi interface went down and it wants to move >>>>>>>>>>> that traffic to another interface. Would the HA reject such mov= e? >>>>>>>>>>> Does the MN have to justify to the HA why it needs to move >>>>>>>>>>> traffic? Does that involve writing a letter perhaps? >>>>>>>>>>> If you say "well in that case, the HA should let the MN move >>>>>>>>>>> the traffic" >>>>>>>>>>> then I'll ask you: what's the point of having the HA install >>>>>>>>>>> this stuff if it has no authority and how does it know the >>>>>>>>>>> reason for the MN's movement of the flow? >>>>>>>>>>> The way to control how users do things is to incentivise them >>>>>>>>>>> with charging models and show them that things work better on >>>>>>>>>>> certain technologies, not by installing rules that can't be >>>>>>>>>>> followed. It's a broken mindset and we've known that it's >>>>>>>>>>> broken for a long time. >>>>>>>>>>>=20 >>>>>>>>>>> 4. Some people mentioned that the HA should be able to revoke >>>>>>>>>>> flows on the MN. I'm perfectly fine with that, just extend >>>>>>>>>>> the binding revocation draft to handle flows and the rest is >>>>>>>>>>> pretty straight forward. >>>>>>>>>>>=20 >>>>>>>>>>> Finally, I'll indulge in a true story that happened to me a >>>>>>>>>>> few years ago when I found that my wifi link wasn't working >>>>>>>>>>> in a hotel (no >>>>>>>>>>> radio) >>>>>>>>>>> and called the help desk. He insisted that the link was up an >>>>>>>>>>> I insisted that it wasn't. When I asked him to tell me how he >>>>>>>>>>> knows the link is up he said: I can ping the AP! Of course >>>>>>>>>>> after another >>>>>>>>>>> 5 minutes of trying to convince him that pinging the AP >>>>>>>>>>> doesn't mean the radio is actually working he sent someone to >>>>>>>>>>> the hotel who in turn realised that the radio was not working. >>>>>>>>>>> For those people who want rules to be transferred from the HA >>>>>>>>>>> to the MN, please think of your HA as this help desk person, i.= e. >>>>>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>>>>=20 >>>>>>>>>>> I hope this helps with the realisation that decisions can't >>>>>>>>>>> be made here based on voting and that there is little merit >>>>>>>>>>> to transferring rules from the HA to the MN. Policies can be >>>>>>>>>>> transferred without any problems, but not rules. >>>>>>>>>>>=20 >>>>>>>>>>> Hesham >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> MEXT mailing list >>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> MEXT mailing list >>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>> _______________________________________________ >>>>>>>>>> MEXT mailing list >>>>>>>>>> MEXT@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From julien.laganier.ietf@googlemail.com Fri Jun 5 03:12:33 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0A33A6812 for ; Fri, 5 Jun 2009 03:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 v6bA3AN1nGFc for ; Fri, 5 Jun 2009 03:12:32 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 25F793A672F for ; Fri, 5 Jun 2009 03:12:31 -0700 (PDT) Received: by fxm9 with SMTP id 9so441055fxm.37 for ; Fri, 05 Jun 2009 03:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oy0XlRgHDOAr70YgMoXcVKDRRlImiqEkD0QE2+06tQM=; b=avIbRk9BfkQD4bUY1ptFV9+2x2Yj2pna4HDRCawZUw5eF5SLVGYQk1stOdo8t/D/RI K0ygNuY5xl33YZlS6T/nlynFgeVeefgvaj4dSKd6IoDRB59H4/M6BOGGNWok3TtkUisX lEXr87kfuQk2UMPXf8HmeG7qxOCkQtPrOYRuQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pgUQTpzgPr+BHcm+3MI3dvvMrZja4xB/co/su7kbRnpSQ3WFbUY8COv/5h5JgL4BeL iafl/8aB9Yl2Ch7C/g0CdzYOyS1q8EGiD4AzgZ1ViD+xugDh2NttqKu5rHqrMbVqVn5c lFLgm3jQ3yMsO/oXzWJv5HZ63JPOWAW4lF+iQ= MIME-Version: 1.0 Received: by 10.204.120.193 with SMTP id e1mr2995471bkr.147.1244196752043; Fri, 05 Jun 2009 03:12:32 -0700 (PDT) In-Reply-To: References: <7ad6d6db0906020542s5b29e869i6b13bd8db989bf43@mail.gmail.com> Date: Fri, 5 Jun 2009 12:12:31 +0200 Message-ID: <7ad6d6db0906050312w7fd0527bp42cc243a432902e6@mail.gmail.com> From: Julien Laganier To: Yuri Ismailov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] Important considerations for directionality of flow bindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 10:12:33 -0000 Yuri, Sorry for the late answer but I had other commitments. Please see inline. On Tue, Jun 2, 2009 at 4:17 PM, Yuri Ismailov wrote: > Julien, > > Probably some missunderstanding comes from the different scope of viewing= at the general deployment of MIP protocol(s) > I'm trying (whether successful or not?) not to restrict the view to just = flow binding as such but to look at somewhat bigger context where MIP suppo= rt is a part of the whole, playing important role. I'm all for looking at the big picture as long as we do not try to use the IP mobility sub-layer for things which are unrelated to IP mobility. If we can agree on this, let's proceed. >> How do you make your HA know that the address XYZ your MN just SLAAC'd a= t the starbucks downdown is assigned towards on a 54Mbs WiFi link? >> Are you driving back to home to configure appropriately your HA while th= e MN stays at starbucks? > > The key is that one may use (I definetly would) applciation level to comm= unicate any kind of parameters between HA and MN. I do not mean routing rul= es. Basically anything else. If one finds that the fact of MN being attache= d to 54Mbs WiFi link is useful information for HA, then there is nothing pr= eventing to send this information to HA without involving MIP. For the purpose of discussing the point above only: If you'd like you can assume that MN and HA are exchanging "any kind of parameters", and thus that the HA knows all the useful information it needs/want to know about the MN context. But once you're making this assumption, you have to let me conversely assume that the MN knows all the useful information it needs/want to know about the HA context. So what's the point? Why do I care devising application layer relationships in a perfect couple while I'm sitting in the Mobile IPv6 Extensions WG in the Internet Area...? > Next important thing, in my view, is that the logic generating this or th= at set of routing rules whether implemented in MN or HA or both has nothing= to do with MIP. This logic is about how to choose an interface for a parti= cular flow and in theory may be delegated to a third party node (do not thi= nk this is a good idea though). This is the reason why I don't entirely agr= ee with your statement: > >> I believe there's a valid reason which is called protocol layering. >> Rules dealing with choice of a MIPv6 Care-of address do belong to the >> MIPv6 layer. Policies regarding which access technology to use for a giv= en app/service/etc. do not belong to that layer I agree with you that the "logic is about how to choose an interface for a particular flow". The point I tried to make above is that once the choice is made (and wherever that happens, e.g. in a third party) and interface X is selected, the enforcement of that choice requires selecting a CoA for the flow, a CoA is a concept that belongs entirely to mobility sub-layer, and the only entity that can derive from "interface X" the CoA to use for the flow is the MN. > Basically rules is instantiation of policies and as I see it, first the c= hoice of access is made, secondly an IP address is pointed out, but not bec= ause the IP address is suitable for a flow or belongs to IP layer, but beca= use it turned out to be configured on the suitable access. Thus, I would no= t state that rules are dealing with any kind of choice, on the other hand r= ules are the result of choice. There we agree again. >> An information is important in a given context. I do not care what's the= status of your WiFi card, I care about the status of my card. >> > > This is sad:-) If you could get a hint about my status, you could possibl= y make a better choice. Not for the sake of analogy, just an example: SIP h= as negotiation procedure of session parameters, which makes things nicer. T= he word "hint" characterizes quite well the fact of sending rules from HA t= o MN. As I wrote earlier, MN does not have to follow the HA generated rules= , however may take into account. Again, wherever the policy is applied in selecting an interface, whatever is the process, using hints, or any other input parameter in the decision, this does not change the fact that the MN only knows which CoA to pick to satisfy the choice of interface resulting of the policy. In my view this is a fact, and I'm guessing this is our main (and only?) point of disagreement. >> 51% majority is not "rough consensus", this is voting. >> > What is the rough consensus then? Who decides that the rough consensus is= achieved? Quoting RFC 2418, a.k.a. IETF Working Group Guidelines and Procedures: "It is up to the Chair to determine if rough consensus has been reached= ." Hope it clarifies. --julien From yuri.ismailov@ericsson.com Fri Jun 5 05:46:41 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D19B3A6407 for ; Fri, 5 Jun 2009 05:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.095 X-Spam-Level: X-Spam-Status: No, score=-8.095 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 pLTqB5eHjGjc for ; Fri, 5 Jun 2009 05:46:38 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 76F0D3A6808 for ; Fri, 5 Jun 2009 05:46:37 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9cae00000140d-2e-4a2913ae0dc7 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id FC.00.05133.EA3192A4; Fri, 5 Jun 2009 14:46:38 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jun 2009 14:46:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Jun 2009 14:46:37 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNg References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 05 Jun 2009 12:46:38.0181 (UTC) FILETIME=[AABBE950:01C9E5DB] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 12:46:41 -0000 Hesham, Let's proceed with sorting out what we are talking about, this probably = will help structuring examples and scenarious My assumptions: (probably shuold have been mentioned earlier) If we will agree on assumptions, then it will make sense to go further = on. First is that I assume that we have simulteneous multiaccess in mind, = i.e. MN has more than one interface to choose from for its flows. If = this is not the case then I will stop the discussion. This assumption is = based on the fact that we are (I hope at least) discussing flow = mobility. Secondly, I consider that MN chooses an interface but not CoA. I gave a = though about that and did not come up with any information which can be = derived from CoA in order to choose it. An interface has at least = expected characteristics, thus can be a subject of choice. Any = clarification about that would be appreciated. Next assumptions are about possible configurations of HA - Single HA for all interfaces configured in the mobile. HA can belong = to any of the access providers of each of access technology used by MN. - One HA per access or set of accesses, which is subset of all access = techologies presented or potentially may be presented (detached devices) = in MN. Anticipating numerous questions about that can say that I looked at such = configuration and did not find anything strange with it, i.e. (1) it = works, (2) it does not require any change to MIP or any other of its = extensions. (3) Configuration is performed per interface and does not = introduce any ambiguities. (4) it is natural for access provider to = offer HA service. - "Residential" HA. Assumption is that it can be either one of HA's or a = single HA for all types of accesses. This is the matter of MN = configuration. "Residential". - Any HA may have multiple interfaces, e.g. "residential" HA may be = connected to mobile broadband, DSL, etc. Next assumption comes from the example (e.g. latest one) - Traffic shaping is applied in both directions (up/down) link (in = practice this is the case). - Traffic shaping (TS) is applied to user subscription. In other words = TS is applied to packets belonging to a particular subscription but not = to an aggregated traffic on gateway interfaces. HA is not necessary = (however, nothing prevents from that) a gateway where TS is applied. I hope that I have not missed something, although it may be possible. If we can agree on that or correct if something is wrong here and agree = later then we know how to proceed further on /yuri -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Friday, June 05, 2009 11:37 AM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings Yuri, > Still not clear for me why you call scenarious invalid? > Some broadband providers (this is used in practice) have quota on the=20 > amount of traffic sent by users. Once quota is exceeded provider=20 > downgardes outgoing traffic from its network to 64Kbs (this figure is=20 > the real example from real provider). Such combination of to paths,=20 > where one is high speed, lets say 10 Mbs and another one is 64Kbs is = quite crusual to apps running on top of TCP. > Not for all types of traffic though. =3D> Yes I know the scenario but I keep saying to you that the change in = upstream routing in the HA has nothing to do with CoA selection by the = MN in the visited network. If anything, you want the MN to change it's = HoA depending on how the switch to another upstream ISP works. It's a = completely irrelevant issue to this discussion. Do you agree? If not why = not? I really want to see an answer to this point. =20 >=20 > MN can not know about this situation. Nobody will send this = information to MN. =3D> Yes and if it knows what will it do??? If you can answer that you = will fix the deadlock we have. > That means that MN will choose its interfaces based on its knowledge=20 > about 10Mbs link capabilities. =3D> You're talking about two different things. The MN doesn't choose = the HA's outgoing interface! What am I missing? Obtaining this isnformation from HA is quite > significant to make a better decision about choice of interfaces for=20 > its flows. > This is concrete example of what happens in the reality. > Do you consider that this information will be useless for MN? =3D> Completely useless. Unless I'm missing something in your scenario. = Just write down step by step what will happen and include messages. I = don't see how this can possibly be relevant to the MN. Hesham Hesham >=20 > /yuri >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Thursday, June 04, 2009 4:38 PM > To: Yuri Ismailov; Nicolas Montavont;=20 > pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of=20 > flowbindings >=20 > Yuri, >=20 >=20 > On 5/06/09 12:01 AM, "Yuri Ismailov" = wrote: >=20 >> Hesham, >>=20 >> I provided several scenarious which you said are invalid. This is=20 >> where my conclusion about standpoint comes from. >> Whether you call hints policies or rules it does not change what=20 >> information can be provided by HA to MN. >=20 > =3D> It changes the outcome for the work item we're discussing. I'm=20 > trying to come to a conclusion on this and there is a huge difference=20 > between transferring policies and installing flow bindings. >=20 >> By sending rules HA does not install anything in MN. Likewise, MN=20 >> does not install rules in HA, it informs HA about currently made = choices. >> As I remember rules will not be valid until proper Ack arrival, which = >> for me means that may not be instantiated at all. >> Niether rules nor polices are specific to MIP. As I wrote those can=20 >> be exchanged between hosts without any MIP implementation, just for=20 >> access selection purposes. Once it was decided to make it as part of=20 >> MIP protocol, I'm fine with that. Do not have any idea to discuss=20 >> this, while personally consider that the work on rules transfer can=20 >> very well fit into the MEXT group but as a separate work item, but=20 >> this is not the case now, so good enough the way it is. >> And back again, it really gets repeated, so will lead to nowhere,=20 >> you've got my arguments and tell that the information, which I'm=20 >> talking about, is not usefull. What can I say more? I can put you on=20 >> my position and start asking questions instead of answering. So, why=20 >> it is not usefull? >=20 > =3D> I explained why the specific information you mentioned was not=20 > useful/useable by the MN and this is what I referred to as unanswered. > Because if you agree with my previous explanations then we don't need=20 > to discuss it further. If you disagree you certainly didn't tell me=20 > why. You have the charge of proof because you want to change the way=20 > MIP works currently, that's all I'm trying to say. >=20 > Hesham >=20 >>=20 >> /yuri >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Thursday, June 04, 2009 4:00 AM >> To: Yuri Ismailov; Nicolas Montavont;=20 >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of=20 >> flowbindings >>=20 >> Yuri, >>=20 >>=20 >>=20 >>> Missing is additional information which may be helpful in making=20 >>> better decision about interface selection by MN. >>> Which information is that I wrote in my previous emails. Back to my=20 >>> examples (not all, do not want to repeat myself). If HA will have=20 >>> changed traffic shaping parameters on one of the incoming or=20 >>> outgoing interfaces, this will be important information for MN to = know. >>> We have agreed already that whether this information important or=20 >>> not, benfitial or not is a matter of standpoint. >>=20 >> =3D> I don't agree or like to think that it's a matter of standpoint. >> That's why I asked you on every point you raised and compared this to = >> the MN's knowledge on e2e basis. Once we have "standpoints" then=20 >> we're getting outside the technical realm. The reason I don't think=20 >> it's useful is that this information cannot be used by the MN to=20 >> select a CoA. I've already stated that before and you seemed to agree = >> so I don't know why you repeat this as a reason for the HA to install = >> filters in the MN. Let me say it >> again: There is no correlation between the routing on the HA's=20 >> upstream interfaces/ISP with the MN's selection of a CoA. >>=20 >>> I consider that knowing more is a benefit and will help to get=20 >>> better result. >>>=20 >>> My point is still the same. I see the reverse rules sending as=20 >>> possibility to provide more information to the MN, thus make MN to=20 >>> get to better decision about interface selection for its flows. This = >>> point has not changed since the beginning of the discussion. >>=20 >> =3D> This is why we're not making progress IMO: >>=20 >> 1. The hints you refer to are not the same things as installing rules = >> on the MN. Completely different information in fact. You've=20 >> essentially proved that when you suggested that the MN can accept or=20 >> reject them. So, let's not call them rules. The more direct word for=20 >> what you want to send is policies >>=20 >> 2. You didn't provide a valid scenario that we can discuss as to why=20 >> it's needed or how it could work. I've asked numerous questions in=20 >> each email that were not answered (with the exception of the last=20 >> email). It's not possible to progress the discussion without=20 >> answering each others' >> questions. You can go back through the threads and verify this. >>=20 >> 3. If we're sending rules from the HA to the MN and the MN can reject = >> those rules then the whole exercise is pointless. You really want to=20 >> send policies not rules. I can imagine those policies being one of=20 >> the inputs that the MN uses to make a decision. I still fail to see=20 >> how anything happening on the HA's upstream interfaces/ISP link can=20 >> possibly influence the MN's decision for CoA selection. This is=20 >> another unanswered question. >>=20 >> Hesham >>=20 >>>=20 >>> /yuri >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Wednesday, June 03, 2009 4:09 PM >>> To: Yuri Ismailov; Nicolas Montavont;=20 >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>> flowbindings >>>=20 >>>=20 >>>=20 >>>=20 >>> On 3/06/09 10:47 PM, "Yuri Ismailov" = wrote: >>>=20 >>>> Ok, see your point, however:-) >>>>=20 >>>> The major difference here is that your are talking about CoA=20 >>>> selection and I'm talking about interface selection. Quite a big=20 >>>> difference. >>>=20 >>> =3D> No, that's not the point really. The point is that there is no=20 >>> relationship between CoA/interface selection on the MN and the=20 >>> upstream ISP for the home network. >>>=20 >>>> I do not see any grounds for MN to select CoA, based on what?=20 >>>> Prefix length? >>>> While selection of an interface is based on expected=20 >>>> characteristics of the communication. Routes (up/down)link in my=20 >>>> opinion do have impact on the characteristics and this is exactly=20 >>>> the information missing in the MN when selecting interface. >>>=20 >>> =3D> There is nothing missing for the MN to make this selection.=20 >>> Please tell us specifically what is missing. You're changing points=20 >>> on me all the time now. >>> Lets stick to one point at a time. What's missing? >>>=20 >>>>=20 >>>> Whenever, MN decides to move a flow, the reason can be anything but = >>>> not which CoA it has configured on each interface. >>>>=20 >>>> Another thing is that MN will notice something e2e if and only if=20 >>>> such support is implemented in the MN. >>>=20 >>> =3D> Of course, so what? >>>=20 >>> Moreover, this notice can not be made at IP layer. >>>> TCP fights alone with all problems and never tells to any other=20 >>>> layer what is going on. So what is left? Two options. Add this=20 >>>> support to operating system, which makes its (support) existence=20 >>>> questionable, or to applications, which is even more questionable. >>>=20 >>> =3D> It's interesting that you think it's questionable to add the=20 >>> support to the MN's OS but not questionable to add the support to=20 >>> the HA's OS, which will not lead to the same reliability as if it=20 >>> were done in the MN. It doesn't make sense to me. >>>=20 >>>>=20 >>>>>>=20 >>>>>> Well, that's debatable, but this is clearly not a reason to do = anything. >>>>>>=20 >>>> Are you serious about that MIP may be broken because of that? >>>=20 >>> =3D> Yes! It's not designed to do what you want to do. Luckily, in=20 >>> this case what you want, IMO, is broken anyway so it's not a = problem. >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> /yuri >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Wednesday, June 03, 2009 1:15 PM >>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>>> flowbindings >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Still some answers, despite knowing that in your opinion they are=20 >>>>> not benefits. >>>>>=20 >>>>> First of all MIP will not be breaked if the rules will be sent in=20 >>>>> both directions. >>>>=20 >>>> =3D> Well, that's debatable, but this is clearly not a reason to do = anything. >>>>=20 >>>>>=20 >>>>> - Access provider preferences relate to the use of backbone=20 >>>>> provider, which may vary with the time of day. Changing backbone=20 >>>>> provider can make quite big difference for commnication between HA = >>>>> (if HA service is provided by the same access provider) and CN(s). >>>>> The difference can be expressed in, let's say, number of hops,=20 >>>>> load, possibly something else. Such change is an event and may=20 >>>>> have an impact on the overall communication. This can be told=20 >>>>> directly to MN or HA. Direct communication to MN (if accepted as=20 >>>>> benefit:-)) in such case will need standardization. Communication=20 >>>>> of this information to HA does not (I consider this as a benefit). = >>>>> HA may act upon that event, and the rest you >>>>> know: rules in reverse direction. >>>>=20 >>>> =3D> There is no need to _tell_ the MN anything. There are two = issues here. >>>> First, changing network conditions are best known e2e. So the MN=20 >>>> will know that anyway based on the traffic running between it and = the CN. >>>> The other issue is related to cost for certain times of day. This=20 >>>> is a routing issue in the HA and has nothing to do with which=20 >>>> interface the MN selects. The selected CoA has zero impact on the=20 >>>> HA's upstream selection. Completely irrelevant actually. >>>> Of course, as far as cost on the visited link, the MN knows best. >>>>=20 >>>>>=20 >>>>> - Access provider may set up different parameters for traffic=20 >>>>> shaping for each of HA interfaces. These preferences may vary=20 >>>>> independently of change of backbone provider but dependently on=20 >>>>> the time of day. >>>>> The rest you know, whether it changes somebodies opinion. >>>>=20 >>>> =3D> But again, this has zero effect on CoA selection. The two = issues=20 >>>> are completely orthogonal. Selecting CoA1 or CoA2 has zero impact=20 >>>> on the HA's upstream route. >>>>=20 >>>>>=20 >>>>> - I presume that in RO mode this is similar to HA mode, and I'm in = >>>>> when it comes to send rules in reverse direction between CN and = MN. >>>>> Benefits of doing that is that any change percieved by CN as=20 >>>>> important to react upon can be expressed in proposal of new rules. >>>>> The sources causing changes may include but not limited to, are=20 >>>>> user, network managemnt events, application generated events, etc. >>>>>=20 >>>>> So feel free to consider this as benefits or not >>>>=20 >>>> =3D> You seem to think that there is a relationship between = upstream=20 >>>> routing and CoA selection. That's not the case at all. These are=20 >>>> two different addresses from two different networks. >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> /yuri >>>>>=20 >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: Wednesday, June 03, 2009 11:47 AM >>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>> pierrick.seite@orange-ftgroup.com >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of = >>>>> flowbindings >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 3/06/09 7:33 PM, "Yuri Ismailov" = wrote: >>>>>=20 >>>>>> Hesham, >>>>>>=20 >>>>>> Whenever we talk about sending additional information, the "waste = >>>>>> of bandwidth" can be brought up. So I do not have an answer for=20 >>>>>> that besides speculations around it. >>>>>=20 >>>>> =3D> no no, I don't mean it literally, I mean that the message=20 >>>>> doesn't do anything, i.e. Has no benefit. >>>>>=20 >>>>>>=20 >>>>>> Speaking about benefits, everybody who knows the area is capable=20 >>>>>> of turning things up side down. I assume it is subjective=20 >>>>>> standpoint of considering things as benefits or disadvantages and = >>>>>> all is about to agree or disagree. >>>>>=20 >>>>> =3D> That's fine, I'm asking for benefits in your opinion not=20 >>>>> someone else's. >>>>> It's impossible to discuss this if I can't see any benefits=20 >>>>> because you didn't send any. What you sent were actions that can=20 >>>>> be done by the HA and I responded by saying that the same (or=20 >>>>> more) information is available to the MN. Therefore, if you think=20 >>>>> there are additional benefits to doing this in the HA then you = need to tell us. >>>>>=20 >>>>> The bottom line is this: MIP works by letting the MN install=20 >>>>> bindings in the HA. If you want things to work in reverse you need = >>>>> to justify it. I can't see any justifications because you're not=20 >>>>> answering my questions on your scenarios. So, count me out on the=20 >>>>> reverse direction :). >>>>>=20 >>>>>=20 >>>>> For >>>>>> me those I wrote about are benefits or potential benefits if you = want. >>>>>=20 >>>>> =3D> No you didn't. You wrote about things that can be done. Many=20 >>>>> things can be done by many entities, the question is why the HA=20 >>>>> and not the MN. >>>>>=20 >>>>>> One important thing in the discussion, although mentioned, but=20 >>>>>> forgotten later is that by making rules distribution one way=20 >>>>>> only, we do create limitation for benefits, or potential benefits = >>>>>> if this sounds better. >>>>>=20 >>>>> =3D> Well, we won't know what we're missing unless someone tells = us. >>>>> So far no one has mentioned the advantages of doing things in the=20 >>>>> reverse direction. >>>>> There is always something missing from a protocol (it's=20 >>>>> engineering), the question us whether it's significant or worth=20 >>>>> the trouble. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>>=20 >>>>>> /yuri >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>> Sent: Wednesday, June 03, 2009 10:10 AM >>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>> pierrick.seite@orange-ftgroup.com >>>>>> Cc: mext@ietf.org >>>>>> Subject: Re: [MEXT] Important considerations for directionality=20 >>>>>> of flowbindings >>>>>>=20 >>>>>> Yuri, >>>>>>=20 >>>>>> I can't parse those events you refer to. I'l answer both emails = here. >>>>>> First the events you refer to: >>>>>>=20 >>>>>>>> - network condition towards CN(s) >>>>>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>>>>=20 >>>>>> =3D> What's the event? A change in those conditions? The MN knows = >>>>>> the conditions of the e2e path as well as or better than the HA. >>>>>> What is the benefit of having the HA send a hint and how reliable = >>>>>> is that hint anyway? >>>>>>=20 >>>>>>>> - Access provider (any access, not necessarily wireless) who=20 >>>>>>>> offeres HA services preferences change >>>>>>=20 >>>>>> =3D> Preferences change to what?? How does it know if such change = >>>>>> works for the MN at all? This is way too vague to be able to=20 >>>>>> discuss tradeoffs. >>>>>>=20 >>>>>>>> - Change of the access provider traffic to another backbone=20 >>>>>>>> provider due to the time of the day. >>>>>>>> - Traffic condition on HA interface, which accepts traffic from = >>>>>>>> MN if MN sends on some particular local interface >>>>>>=20 >>>>>> =3D> These are path changes. The HA has _no idea_ how such a = change=20 >>>>>> affects each MN/CN combination and it's "hint" can cause more=20 >>>>>> problems than it solves. BTW, if you're talking about hints then=20 >>>>>> we're no longer talking about installing bindings in the MN. This = >>>>>> is a different topic. MIP doesn't transfer hints, it pretty much=20 >>>>>> sends "orders" >>>>>> from one end to another. >>>>>>=20 >>>>>> Now to the actions required by the MN: >>>>>>=20 >>>>>>> - reject, >>>>>>> - re-evaluate and reject >>>>>>> - re-evaluate and accept >>>>>>> - accept >>>>>>=20 >>>>>> =3D> First, by assuming that the MN can reject the "hint" as you=20 >>>>>> call it you invalidate the whole argument for the HA to install = rules. >>>>>> Rejecting a hint or even evaluating it means that the MN knows = more. >>>>>> Therefore, the HA's hint is a complete waste of bandwidth. >>>>>>=20 >>>>>> I'm still confused about the _benefits_ you see here. Or are you=20 >>>>>> assuming that the MN can't know those hints without the HA's=20 >>>>>> involvement? But if you're assuming that, then how can it reject=20 >>>>>> the hints? This whole proposal makes no sense to me at all. Not=20 >>>>>> to mention the complexity you implicitly assume in order to=20 >>>>>> generate those, hopefully reliable, hints. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>=20 >>>>>> On 3/06/09 5:23 PM, "Yuri Ismailov" = wrote: >>>>>>=20 >>>>>>> Hesham, >>>>>>>=20 >>>>>>> In my view these are events not scenarious. These events are=20 >>>>>>> known by HA but not MN. If HA acts upon events, given that it=20 >>>>>>> knows somewhat more about MN, not only IP addresses, it (HA) can = >>>>>>> generate new rules and send them as hint to MN. Back again, MN=20 >>>>>>> has four >>>>>>> options: >>>>>>>=20 >>>>>>> The benefit will be obviously that the new rules (if accepted)=20 >>>>>>> may llead to a better overall communication characteristics. >>>>>>>=20 >>>>>>> /yuri >>>>>>>=20 >>>>>>>=20 >>>>>>> =3D> I'm trying to understand what you mean above. These are all = >>>>>>> scenarios, the question is: What is the benefit for the HA to=20 >>>>>>> transfer rules? The HA will not know the path between the MN and = >>>>>>> CN more than either node does. So I don't understand what=20 >>>>>>> _benefits_ you see here. >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Pretty much sure that there are more examples and I encourage=20 >>>>>>>> to think about those not from MN point of view but rather from=20 >>>>>>>> the HA service provider. >>>>>>>>=20 >>>>>>>> /yuri >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>> Cc: mext@ietf.org >>>>>>>> Subject: Re: [MEXT] Important considerations for directionality = >>>>>>>> of flowbindings >>>>>>>>=20 >>>>>>>> Yuri, >>>>>>>>=20 >>>>>>>> It is just rules TRANSFER which is the matter of MIP. So where >>>>>>>>> is the logic when saying that MN to HA rules transfer is a=20 >>>>>>>>> practical engineering and HA to MN is an academic interest? >>>>>>>>=20 >>>>>>>> =3D> I think we've (I'm including myself) highlighted several=20 >>>>>>>> reasons for why it makes little sense to transfer rules from HA = to MN. >>>>>>>> Instead of rat-holing on theory Vs practice, you (or others=20 >>>>>>>> advocating the other direction) need to come up with reasons=20 >>>>>>>> for doing things this way. This way we can think like engineers = >>>>>>>> about tradeoffs. >>>>>>>> Absent that, I don't see any point in having theory Vs practice = >>>>>>>> high level discussions, which will lead nowhere. >>>>>>>>=20 >>>>>>>> Hesham >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards >>>>>>>>> Yuri >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>> directionality of flowbindings >>>>>>>>>=20 >>>>>>>>> Hi Pierrick, >>>>>>>>>=20 >>>>>>>>> On Jun 2, 2009, at 4:11 PM, = wrote: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Hi all, >>>>>>>>>>=20 >>>>>>>>>> Please see inline comment. >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>> Pierrick >>>>>>>>>>=20 >>>>>>>>>>> ________________________________________ >>>>>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De = >>>>>>>>>>> la part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 = 09:35 =C0 : >>>>>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important=20 >>>>>>>>>>> considerations for directionality of flowbindings >>>>>>>>>>>=20 >>>>>>>>>>> Hesham, >>>>>>>>>>> This is nice story and makes some sense for the discssion,=20 >>>>>>>>>>> however some details are ommited. In your adventure with the = >>>>>>>>>>> helpdesk, it (the >>>>>>>>>>> helpdesk) is a third party service and thus your conclusions = >>>>>>>>>>> make sence. >>>>>>>>>>> Think of the situation when superior of a heldesk person=20 >>>>>>>>>>> will tell him/her to check access point in some room. Would=20 >>>>>>>>>>> it be the same reaction? I assume not. By that I mean that=20 >>>>>>>>>>> if, for example, I'll install home agent in my home network, = >>>>>>>>>>> I can make it know anything I want about MN, and more=20 >>>>>>>>>>> intresting is that how I will do it, does not require any = standardization. >>>>>>>>>>> In other words, I'm superior of my HA. >>>>>>>>>>> This situation is not unthinkable, I personally believe that = >>>>>>>>>>> this is much more efficient way of using HA fnctionality as=20 >>>>>>>>>>> opposed to big service providers who will have to fight with = >>>>>>>>>>> scalability and performance. >>>>>>>>>>> However, one does not exclude another. >>>>>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> The difference between policy and rules is not only a matter=20 >>>>>>>>>> of conversion. A policy, is a static, or quasi-static, set of = >>>>>>>>>> guidance for the MN (e.g use access network X for application = >>>>>>>>>> type >>>>>>>>>> A,...) while a rule update requires to be more dynamic. I = mean: >>>>>>>>>> eventually a policy could be updated depending on network=20 >>>>>>>>>> condition (e.g if X overloaded, use access network Y for=20 >>>>>>>>>> application type A,...) but a rule reacts on local triggers = (e.g. >>>>>>>>>> modification of the radio link >>>>>>>>>> quality) with a shorter period of variation. So, IMHO, there=20 >>>>>>>>>> is no requirement for updating policy on a short period and=20 >>>>>>>>>> out-of-band mechanism can be used (e.g. IEEE 802.21 in push=20 >>>>>>>>>> mode,...). >>>>>>>>>=20 >>>>>>>>> Fully agree! >>>>>>>>> This is why I do not support the exchange of rules from the HA = >>>>>>>>> to the MN. >>>>>>>>> Policies may be exchanged from the HA to the MN, but MIP is=20 >>>>>>>>> definitely not the protocol to transport them. >>>>>>>>>=20 >>>>>>>>> Nicolas >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> My 2 cents... >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Is there any reason to restrict where such convertion takes = place? >>>>>>>>>>> True >>>>>>>>>>> that a HA does not know what is going on in the access=20 >>>>>>>>>>> network, on the other hand HA may know what is the network=20 >>>>>>>>>>> condition between HA and correspondent node. Either of this=20 >>>>>>>>>>> information is important, if not equally important. >>>>>>>>>>> It is not really difficult to let an MN to reject rules sent = >>>>>>>>>>> by HA, which in my view would be quite natural. This implies = >>>>>>>>>>> that HA must follow the rules installed by MN until explicit = >>>>>>>>>>> acceptance has been received from MN. >>>>>>>>>>> Such procedure is very similar to an MN beahviour when=20 >>>>>>>>>>> initiating new BU, where MN is not supposed to send any=20 >>>>>>>>>>> traffic before BU confirmation. >>>>>>>>>>> BTW, what is the numerical representation of "rough = consensus"? >>>>>>>>>>> I assume is when majority is for, is it so? >>>>>>>>>>> Yuri >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Hesham Soliman >>>>>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>>>>> To: mext >>>>>>>>>>> Subject: [MEXT] Important considerations for directionality=20 >>>>>>>>>>> of flow bindings >>>>>>>>>>>=20 >>>>>>>>>>> Hi all, >>>>>>>>>>>=20 >>>>>>>>>>> I've always been a fan of the IETF's tradition of rough=20 >>>>>>>>>>> concensus (as opposed to voting). To me, this implies that=20 >>>>>>>>>>> you need to get your point across and get other people to=20 >>>>>>>>>>> see that point of view. >>>>>>>>>>> As opposed to other organisations that require their members = >>>>>>>>>>> to vote and end up with rigid political positions. >>>>>>>>>>>=20 >>>>>>>>>>> The chairs asked us about the directionality question of the = >>>>>>>>>>> flows bindings. >>>>>>>>>>> On the charter question, I said that the charter doesn't=20 >>>>>>>>>>> need to mention how a solution should work, but rather what=20 >>>>>>>>>>> problem needs to be solved. >>>>>>>>>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>>>>>>>>> transferring rules "between" the MN and HA without=20 >>>>>>>>>>> mentioning directions. >>>>>>>>>>>=20 >>>>>>>>>>> Nevertheless, we still need to agree on identifying the=20 >>>>>>>>>>> requirement for the solution. And when it comes to this, I'm = >>>>>>>>>>> strongly against voting and I'll practice this by explaining = >>>>>>>>>>> in this email why I think rules can not be transferred from=20 >>>>>>>>>>> the HA to the MN and that the only direction that makes=20 >>>>>>>>>>> sense in MIP is >>>>>>>>>>> MN->HA. I'll deliberately ignore arguments like "some people = >>>>>>>>>>> MN->want >>>>>>>>>>> this" or "an SDO wants this". They fall under the=20 >>>>>>>>>>> "meaningless words" >>>>>>>>>>> category and I'm incapable of discussing them because they=20 >>>>>>>>>>> come with voting attitudes. They all need to be justified if = >>>>>>>>>>> the WG wants to have a technical _discussion_. >>>>>>>>>>>=20 >>>>>>>>>>> Here are my reasons: >>>>>>>>>>>=20 >>>>>>>>>>> 1. The HA does not know whether a CoA is tied to a certain=20 >>>>>>>>>>> access technology. It is one thing for the HA to send a=20 >>>>>>>>>>> message saying "forward port 80 traffic on a wifi link" (a >>>>>>>>>>> policy) and a completely different thing to say "forward=20 >>>>>>>>>>> port 80 traffic using CoA 3ffe::1" >>>>>>>>>>> (a rule). >>>>>>>>>>>=20 >>>>>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem now? >>>>>>>>>>> The problem is that the HA has no idea about dynamic changes = >>>>>>>>>>> on that wifi link. It doesn't know if it's congested, it=20 >>>>>>>>>>> doesn't know what application is using port 80 (it doesn't=20 >>>>>>>>>>> have to be web >>>>>>>>>>> traffic) or port 8000 for that matter and doesn't even know=20 >>>>>>>>>>> if the AP of that wifi link works at all. >>>>>>>>>>> Finally, it >>>>>>>>>>> doesn't know the user's policies or other admin policies for = >>>>>>>>>>> that MN. >>>>>>>>>>> This type of information needs to be sent regularly because=20 >>>>>>>>>>> it changes all the time and requires serious cross layer=20 >>>>>>>>>>> integration including sometimes layer 8 integration! It's=20 >>>>>>>>>>> completely impractical. >>>>>>>>>>>=20 >>>>>>>>>>> 3. If the HA installed rules in the MN, what happens if the=20 >>>>>>>>>>> MN wants to change those rules. Say the wifi link went down, = >>>>>>>>>>> or the MN's wifi interface went down and it wants to move=20 >>>>>>>>>>> that traffic to another interface. Would the HA reject such = move? >>>>>>>>>>> Does the MN have to justify to the HA why it needs to move=20 >>>>>>>>>>> traffic? Does that involve writing a letter perhaps? >>>>>>>>>>> If you say "well in that case, the HA should let the MN move = >>>>>>>>>>> the traffic" >>>>>>>>>>> then I'll ask you: what's the point of having the HA install = >>>>>>>>>>> this stuff if it has no authority and how does it know the=20 >>>>>>>>>>> reason for the MN's movement of the flow? >>>>>>>>>>> The way to control how users do things is to incentivise=20 >>>>>>>>>>> them with charging models and show them that things work=20 >>>>>>>>>>> better on certain technologies, not by installing rules that = >>>>>>>>>>> can't be followed. It's a broken mindset and we've known=20 >>>>>>>>>>> that it's broken for a long time. >>>>>>>>>>>=20 >>>>>>>>>>> 4. Some people mentioned that the HA should be able to=20 >>>>>>>>>>> revoke flows on the MN. I'm perfectly fine with that, just=20 >>>>>>>>>>> extend the binding revocation draft to handle flows and the=20 >>>>>>>>>>> rest is pretty straight forward. >>>>>>>>>>>=20 >>>>>>>>>>> Finally, I'll indulge in a true story that happened to me a=20 >>>>>>>>>>> few years ago when I found that my wifi link wasn't working=20 >>>>>>>>>>> in a hotel (no >>>>>>>>>>> radio) >>>>>>>>>>> and called the help desk. He insisted that the link was up=20 >>>>>>>>>>> an I insisted that it wasn't. When I asked him to tell me=20 >>>>>>>>>>> how he knows the link is up he said: I can ping the AP! Of=20 >>>>>>>>>>> course after another >>>>>>>>>>> 5 minutes of trying to convince him that pinging the AP=20 >>>>>>>>>>> doesn't mean the radio is actually working he sent someone=20 >>>>>>>>>>> to the hotel who in turn realised that the radio was not = working. >>>>>>>>>>> For those people who want rules to be transferred from the=20 >>>>>>>>>>> HA to the MN, please think of your HA as this help desk = person, i.e. >>>>>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>>>>=20 >>>>>>>>>>> I hope this helps with the realisation that decisions can't=20 >>>>>>>>>>> be made here based on voting and that there is little merit=20 >>>>>>>>>>> to transferring rules from the HA to the MN. Policies can be = >>>>>>>>>>> transferred without any problems, but not rules. >>>>>>>>>>>=20 >>>>>>>>>>> Hesham >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> MEXT mailing list >>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> MEXT mailing list >>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>> _______________________________________________ >>>>>>>>>> MEXT mailing list >>>>>>>>>> MEXT@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From yuri.ismailov@ericsson.com Fri Jun 5 06:09:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E018F3A6D3C for ; Fri, 5 Jun 2009 06:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.106 X-Spam-Level: X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 uCIGn2fvvren for ; Fri, 5 Jun 2009 06:09:19 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id DB8813A6ADC for ; Fri, 5 Jun 2009 06:09:15 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9cae00000140d-fb-4a2918fd0e9e Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 1A.72.05133.DF8192A4; Fri, 5 Jun 2009 15:09:17 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jun 2009 15:09:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Jun 2009 15:09:16 +0200 Message-ID: In-Reply-To: <7ad6d6db0906050312w7fd0527bp42cc243a432902e6@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flow bindings Thread-Index: AcnlxiVZnBbrE8BpQU+gzuc/t2J8cAAF6A/Q References: <7ad6d6db0906020542s5b29e869i6b13bd8db989bf43@mail.gmail.com> <7ad6d6db0906050312w7fd0527bp42cc243a432902e6@mail.gmail.com> From: "Yuri Ismailov" To: "Julien Laganier" X-OriginalArrivalTime: 05 Jun 2009 13:09:16.0702 (UTC) FILETIME=[D479C3E0:01C9E5DE] X-Brightmail-Tracker: AAAAAA== Cc: mext Subject: Re: [MEXT] Important considerations for directionality of flow bindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 13:09:21 -0000 Julien, I agree entirely with your comment about Internet area and support of a perfect couple. I wrote many times that this is not the place for such standardization or may be does not have to be standardized at all because in many cases it probably will not exposed to the outside world, just staying in an administrative domain. I'm trying to focus on flow mobility and a best possible match between available interfaces and flow requirements under policies constraints. I made an attempt to summarize my assumptions (my last email) in order to see if there is any future of this discussion. If we will not agree on assumptions then there is no reason in convincing anybody /yuri -----Original Message----- From: Julien Laganier [mailto:julien.laganier.ietf@googlemail.com]=20 Sent: Friday, June 05, 2009 12:13 PM To: Yuri Ismailov Cc: mext Subject: Re: [MEXT] Important considerations for directionality of flow bindings Yuri, Sorry for the late answer but I had other commitments. Please see inline. On Tue, Jun 2, 2009 at 4:17 PM, Yuri Ismailov wrote: > Julien, > > Probably some missunderstanding comes from the different scope of=20 > viewing at the general deployment of MIP protocol(s) I'm trying (whether successful or not?) not to restrict the view to just flow binding as such but to look at somewhat bigger context where MIP support is a part of the whole, playing important role. I'm all for looking at the big picture as long as we do not try to use the IP mobility sub-layer for things which are unrelated to IP mobility. If we can agree on this, let's proceed. >> How do you make your HA know that the address XYZ your MN just SLAAC'd at the starbucks downdown is assigned towards on a 54Mbs WiFi link? >> Are you driving back to home to configure appropriately your HA while the MN stays at starbucks? > > The key is that one may use (I definetly would) applciation level to communicate any kind of parameters between HA and MN. I do not mean routing rules. Basically anything else. If one finds that the fact of MN being attached to 54Mbs WiFi link is useful information for HA, then there is nothing preventing to send this information to HA without involving MIP. For the purpose of discussing the point above only: If you'd like you can assume that MN and HA are exchanging "any kind of parameters", and thus that the HA knows all the useful information it needs/want to know about the MN context. But once you're making this assumption, you have to let me conversely assume that the MN knows all the useful information it needs/want to know about the HA context. So what's the point? Why do I care devising application layer relationships in a perfect couple while I'm sitting in the Mobile IPv6 Extensions WG in the Internet Area...? > Next important thing, in my view, is that the logic generating this or that set of routing rules whether implemented in MN or HA or both has nothing to do with MIP. This logic is about how to choose an interface for a particular flow and in theory may be delegated to a third party node (do not think this is a good idea though). This is the reason why I don't entirely agree with your statement: > >> I believe there's a valid reason which is called protocol layering. >> Rules dealing with choice of a MIPv6 Care-of address do belong to the >> MIPv6 layer. Policies regarding which access technology to use for a=20 >> given app/service/etc. do not belong to that layer I agree with you that the "logic is about how to choose an interface for a particular flow". The point I tried to make above is that once the choice is made (and wherever that happens, e.g. in a third party) and interface X is selected, the enforcement of that choice requires selecting a CoA for the flow, a CoA is a concept that belongs entirely to mobility sub-layer, and the only entity that can derive from "interface X" the CoA to use for the flow is the MN. > Basically rules is instantiation of policies and as I see it, first the choice of access is made, secondly an IP address is pointed out, but not because the IP address is suitable for a flow or belongs to IP layer, but because it turned out to be configured on the suitable access. Thus, I would not state that rules are dealing with any kind of choice, on the other hand rules are the result of choice. There we agree again. >> An information is important in a given context. I do not care what's the status of your WiFi card, I care about the status of my card. >> > > This is sad:-) If you could get a hint about my status, you could possibly make a better choice. Not for the sake of analogy, just an example: SIP has negotiation procedure of session parameters, which makes things nicer. The word "hint" characterizes quite well the fact of sending rules from HA to MN. As I wrote earlier, MN does not have to follow the HA generated rules, however may take into account. Again, wherever the policy is applied in selecting an interface, whatever is the process, using hints, or any other input parameter in the decision, this does not change the fact that the MN only knows which CoA to pick to satisfy the choice of interface resulting of the policy. In my view this is a fact, and I'm guessing this is our main (and only?) point of disagreement. >> 51% majority is not "rough consensus", this is voting. >> > What is the rough consensus then? Who decides that the rough consensus is achieved? Quoting RFC 2418, a.k.a. IETF Working Group Guidelines and Procedures: "It is up to the Chair to determine if rough consensus has been reached." Hope it clarifies. --julien From hesham@elevatemobile.com Fri Jun 5 07:18:16 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C87963A6C28 for ; Fri, 5 Jun 2009 07:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 fbDoKHqLW5RB for ; Fri, 5 Jun 2009 07:18:13 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 58A733A6997 for ; Fri, 5 Jun 2009 07:18:12 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MCaF7-0003Eq-1M; Sat, 06 Jun 2009 00:18:03 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Sat, 06 Jun 2009 00:17:54 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDA= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 14:18:16 -0000 > First is that I assume that we have simulteneous multiaccess in mind, i.e= . MN > has more than one interface to choose from for its flows. If this is not = the > case then I will stop the discussion. This assumption is based on the fac= t > that we are (I hope at least) discussing flow mobility. =3D> Sure. >=20 > Secondly, I consider that MN chooses an interface but not CoA. I gave a t= hough > about that and did not come up with any information which can be derived = from > CoA in order to choose it. An interface has at least expected characteris= tics, > thus can be a subject of choice. Any clarification about that would be > appreciated. =3D> An application would choose an interface, but of course the IP stack selects the corresponding address. I'm sure there is no disagreement there. >=20 > Next assumptions are about possible configurations of HA > - Single HA for all interfaces configured in the mobile. HA can belong to= any > of the access providers of each of access technology used by MN. =3D> Ok. >=20 > - One HA per access or set of accesses, which is subset of all access > techologies presented or potentially may be presented (detached devices) = in > MN. =3D> Now you're getting into a different problem space from flow mobility. This is why I wanted you to break the scenario down. We are not dealing wit= h multiple HoAs in this work item, we're dealing with multiple CoAs, i.e. One HoA. > Anticipating numerous questions about that can say that I looked at such > configuration and did not find anything strange with it, i.e. (1) it work= s, > (2) it does not require any change to MIP or any other of its extensions.= (3) > Configuration is performed per interface and does not introduce any > ambiguities. (4) it is natural for access provider to offer HA service. =3D> Yes of course it works but as I read this I'm guessing that you want the MN to change HoA. This is not the problem we're discussing in this WG. Another issue, I'm not comfortable with the wording of "HA per access" because they're not tied to access. Let's just say there are multiple Has and not associate it with an access. >=20 > - "Residential" HA. Assumption is that it can be either one of HA's or a > single HA for all types of accesses. This is the matter of MN configurati= on. > "Residential". =3D> Please don't tie HA to access. >=20 > - Any HA may have multiple interfaces, e.g. "residential" HA may be conne= cted > to mobile broadband, DSL, etc. =3D> sure >=20 > Next assumption comes from the example (e.g. latest one) > - Traffic shaping is applied in both directions (up/down) link (in practi= ce > this is the case). > - Traffic shaping (TS) is applied to user subscription. In other words TS= is > applied to packets belonging to a particular subscription but not to an > aggregated traffic on gateway interfaces. HA is not necessary (however, > nothing prevents from that) a gateway where TS is applied. >=20 >=20 > I hope that I have not missed something, although it may be possible. > If we can agree on that or correct if something is wrong here and agree l= ater > then we know how to proceed further on =3D> Your scenario is fine (with the wording changes for tying Has to access)= . But I want to pre-empt any suggestion that the HA will tell the MN to use a different HoA. This is very possible but it's not the problem being discussed here. It may well be something for charter discussion but it has zero impact on flow bindings for multiple CoAs. Hesham >=20 > /yuri >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Friday, June 05, 2009 11:37 AM > To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of > flowbindings >=20 > Yuri, >=20 >=20 >> Still not clear for me why you call scenarious invalid? >> Some broadband providers (this is used in practice) have quota on the >> amount of traffic sent by users. Once quota is exceeded provider >> downgardes outgoing traffic from its network to 64Kbs (this figure is >> the real example from real provider). Such combination of to paths, >> where one is high speed, lets say 10 Mbs and another one is 64Kbs is qui= te >> crusual to apps running on top of TCP. >> Not for all types of traffic though. >=20 > =3D> Yes I know the scenario but I keep saying to you that the change in > upstream routing in the HA has nothing to do with CoA selection by the MN= in > the visited network. If anything, you want the MN to change it's HoA depe= nding > on how the switch to another upstream ISP works. It's a completely irrele= vant > issue to this discussion. Do you agree? If not why not? I really want to = see > an answer to this point. >=20 > =20 >=20 >=20 >>=20 >> MN can not know about this situation. Nobody will send this information = to >> MN. >=20 > =3D> Yes and if it knows what will it do??? If you can answer that you will= fix > the deadlock we have. >=20 >> That means that MN will choose its interfaces based on its knowledge >> about 10Mbs link capabilities. >=20 > =3D> You're talking about two different things. The MN doesn't choose the H= A's > outgoing interface! What am I missing? >=20 > Obtaining this isnformation from HA is quite >> significant to make a better decision about choice of interfaces for >> its flows. >> This is concrete example of what happens in the reality. >> Do you consider that this information will be useless for MN? >=20 > =3D> Completely useless. Unless I'm missing something in your scenario. Jus= t > write down step by step what will happen and include messages. I don't se= e how > this can possibly be relevant to the MN. >=20 > Hesham >=20 > Hesham >=20 >>=20 >> /yuri >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Thursday, June 04, 2009 4:38 PM >> To: Yuri Ismailov; Nicolas Montavont; >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of >> flowbindings >>=20 >> Yuri, >>=20 >>=20 >> On 5/06/09 12:01 AM, "Yuri Ismailov" wrote: >>=20 >>> Hesham, >>>=20 >>> I provided several scenarious which you said are invalid. This is >>> where my conclusion about standpoint comes from. >>> Whether you call hints policies or rules it does not change what >>> information can be provided by HA to MN. >>=20 >> =3D> It changes the outcome for the work item we're discussing. I'm >> trying to come to a conclusion on this and there is a huge difference >> between transferring policies and installing flow bindings. >>=20 >>> By sending rules HA does not install anything in MN. Likewise, MN >>> does not install rules in HA, it informs HA about currently made choice= s. >>> As I remember rules will not be valid until proper Ack arrival, which >>> for me means that may not be instantiated at all. >>> Niether rules nor polices are specific to MIP. As I wrote those can >>> be exchanged between hosts without any MIP implementation, just for >>> access selection purposes. Once it was decided to make it as part of >>> MIP protocol, I'm fine with that. Do not have any idea to discuss >>> this, while personally consider that the work on rules transfer can >>> very well fit into the MEXT group but as a separate work item, but >>> this is not the case now, so good enough the way it is. >>> And back again, it really gets repeated, so will lead to nowhere, >>> you've got my arguments and tell that the information, which I'm >>> talking about, is not usefull. What can I say more? I can put you on >>> my position and start asking questions instead of answering. So, why >>> it is not usefull? >>=20 >> =3D> I explained why the specific information you mentioned was not >> useful/useable by the MN and this is what I referred to as unanswered. >> Because if you agree with my previous explanations then we don't need >> to discuss it further. If you disagree you certainly didn't tell me >> why. You have the charge of proof because you want to change the way >> MIP works currently, that's all I'm trying to say. >>=20 >> Hesham >>=20 >>>=20 >>> /yuri >>>=20 >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Thursday, June 04, 2009 4:00 AM >>> To: Yuri Ismailov; Nicolas Montavont; >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of >>> flowbindings >>>=20 >>> Yuri, >>>=20 >>>=20 >>>=20 >>>> Missing is additional information which may be helpful in making >>>> better decision about interface selection by MN. >>>> Which information is that I wrote in my previous emails. Back to my >>>> examples (not all, do not want to repeat myself). If HA will have >>>> changed traffic shaping parameters on one of the incoming or >>>> outgoing interfaces, this will be important information for MN to know= . >>>> We have agreed already that whether this information important or >>>> not, benfitial or not is a matter of standpoint. >>>=20 >>> =3D> I don't agree or like to think that it's a matter of standpoint. >>> That's why I asked you on every point you raised and compared this to >>> the MN's knowledge on e2e basis. Once we have "standpoints" then >>> we're getting outside the technical realm. The reason I don't think >>> it's useful is that this information cannot be used by the MN to >>> select a CoA. I've already stated that before and you seemed to agree >>> so I don't know why you repeat this as a reason for the HA to install >>> filters in the MN. Let me say it >>> again: There is no correlation between the routing on the HA's >>> upstream interfaces/ISP with the MN's selection of a CoA. >>>=20 >>>> I consider that knowing more is a benefit and will help to get >>>> better result. >>>>=20 >>>> My point is still the same. I see the reverse rules sending as >>>> possibility to provide more information to the MN, thus make MN to >>>> get to better decision about interface selection for its flows. This >>>> point has not changed since the beginning of the discussion. >>>=20 >>> =3D> This is why we're not making progress IMO: >>>=20 >>> 1. The hints you refer to are not the same things as installing rules >>> on the MN. Completely different information in fact. You've >>> essentially proved that when you suggested that the MN can accept or >>> reject them. So, let's not call them rules. The more direct word for >>> what you want to send is policies >>>=20 >>> 2. You didn't provide a valid scenario that we can discuss as to why >>> it's needed or how it could work. I've asked numerous questions in >>> each email that were not answered (with the exception of the last >>> email). It's not possible to progress the discussion without >>> answering each others' >>> questions. You can go back through the threads and verify this. >>>=20 >>> 3. If we're sending rules from the HA to the MN and the MN can reject >>> those rules then the whole exercise is pointless. You really want to >>> send policies not rules. I can imagine those policies being one of >>> the inputs that the MN uses to make a decision. I still fail to see >>> how anything happening on the HA's upstream interfaces/ISP link can >>> possibly influence the MN's decision for CoA selection. This is >>> another unanswered question. >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> /yuri >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Wednesday, June 03, 2009 4:09 PM >>>> To: Yuri Ismailov; Nicolas Montavont; >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of >>>> flowbindings >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 3/06/09 10:47 PM, "Yuri Ismailov" wrot= e: >>>>=20 >>>>> Ok, see your point, however:-) >>>>>=20 >>>>> The major difference here is that your are talking about CoA >>>>> selection and I'm talking about interface selection. Quite a big >>>>> difference. >>>>=20 >>>> =3D> No, that's not the point really. The point is that there is no >>>> relationship between CoA/interface selection on the MN and the >>>> upstream ISP for the home network. >>>>=20 >>>>> I do not see any grounds for MN to select CoA, based on what? >>>>> Prefix length? >>>>> While selection of an interface is based on expected >>>>> characteristics of the communication. Routes (up/down)link in my >>>>> opinion do have impact on the characteristics and this is exactly >>>>> the information missing in the MN when selecting interface. >>>>=20 >>>> =3D> There is nothing missing for the MN to make this selection. >>>> Please tell us specifically what is missing. You're changing points >>>> on me all the time now. >>>> Lets stick to one point at a time. What's missing? >>>>=20 >>>>>=20 >>>>> Whenever, MN decides to move a flow, the reason can be anything but >>>>> not which CoA it has configured on each interface. >>>>>=20 >>>>> Another thing is that MN will notice something e2e if and only if >>>>> such support is implemented in the MN. >>>>=20 >>>> =3D> Of course, so what? >>>>=20 >>>> Moreover, this notice can not be made at IP layer. >>>>> TCP fights alone with all problems and never tells to any other >>>>> layer what is going on. So what is left? Two options. Add this >>>>> support to operating system, which makes its (support) existence >>>>> questionable, or to applications, which is even more questionable. >>>>=20 >>>> =3D> It's interesting that you think it's questionable to add the >>>> support to the MN's OS but not questionable to add the support to >>>> the HA's OS, which will not lead to the same reliability as if it >>>> were done in the MN. It doesn't make sense to me. >>>>=20 >>>>>=20 >>>>>>>=20 >>>>>>> Well, that's debatable, but this is clearly not a reason to do anyt= hing. >>>>>>>=20 >>>>> Are you serious about that MIP may be broken because of that? >>>>=20 >>>> =3D> Yes! It's not designed to do what you want to do. Luckily, in >>>> this case what you want, IMO, is broken anyway so it's not a problem. >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> /yuri >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: Wednesday, June 03, 2009 1:15 PM >>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>> pierrick.seite@orange-ftgroup.com >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of >>>>> flowbindings >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Still some answers, despite knowing that in your opinion they are >>>>>> not benefits. >>>>>>=20 >>>>>> First of all MIP will not be breaked if the rules will be sent in >>>>>> both directions. >>>>>=20 >>>>> =3D> Well, that's debatable, but this is clearly not a reason to do >>>>> anything. >>>>>=20 >>>>>>=20 >>>>>> - Access provider preferences relate to the use of backbone >>>>>> provider, which may vary with the time of day. Changing backbone >>>>>> provider can make quite big difference for commnication between HA >>>>>> (if HA service is provided by the same access provider) and CN(s). >>>>>> The difference can be expressed in, let's say, number of hops, >>>>>> load, possibly something else. Such change is an event and may >>>>>> have an impact on the overall communication. This can be told >>>>>> directly to MN or HA. Direct communication to MN (if accepted as >>>>>> benefit:-)) in such case will need standardization. Communication >>>>>> of this information to HA does not (I consider this as a benefit). >>>>>> HA may act upon that event, and the rest you >>>>>> know: rules in reverse direction. >>>>>=20 >>>>> =3D> There is no need to _tell_ the MN anything. There are two issues h= ere. >>>>> First, changing network conditions are best known e2e. So the MN >>>>> will know that anyway based on the traffic running between it and the= CN. >>>>> The other issue is related to cost for certain times of day. This >>>>> is a routing issue in the HA and has nothing to do with which >>>>> interface the MN selects. The selected CoA has zero impact on the >>>>> HA's upstream selection. Completely irrelevant actually. >>>>> Of course, as far as cost on the visited link, the MN knows best. >>>>>=20 >>>>>>=20 >>>>>> - Access provider may set up different parameters for traffic >>>>>> shaping for each of HA interfaces. These preferences may vary >>>>>> independently of change of backbone provider but dependently on >>>>>> the time of day. >>>>>> The rest you know, whether it changes somebodies opinion. >>>>>=20 >>>>> =3D> But again, this has zero effect on CoA selection. The two issues >>>>> are completely orthogonal. Selecting CoA1 or CoA2 has zero impact >>>>> on the HA's upstream route. >>>>>=20 >>>>>>=20 >>>>>> - I presume that in RO mode this is similar to HA mode, and I'm in >>>>>> when it comes to send rules in reverse direction between CN and MN. >>>>>> Benefits of doing that is that any change percieved by CN as >>>>>> important to react upon can be expressed in proposal of new rules. >>>>>> The sources causing changes may include but not limited to, are >>>>>> user, network managemnt events, application generated events, etc. >>>>>>=20 >>>>>> So feel free to consider this as benefits or not >>>>>=20 >>>>> =3D> You seem to think that there is a relationship between upstream >>>>> routing and CoA selection. That's not the case at all. These are >>>>> two different addresses from two different networks. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>>=20 >>>>>> /yuri >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>> Sent: Wednesday, June 03, 2009 11:47 AM >>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>> pierrick.seite@orange-ftgroup.com >>>>>> Cc: mext@ietf.org >>>>>> Subject: Re: [MEXT] Important considerations for directionality of >>>>>> flowbindings >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 3/06/09 7:33 PM, "Yuri Ismailov" wro= te: >>>>>>=20 >>>>>>> Hesham, >>>>>>>=20 >>>>>>> Whenever we talk about sending additional information, the "waste >>>>>>> of bandwidth" can be brought up. So I do not have an answer for >>>>>>> that besides speculations around it. >>>>>>=20 >>>>>> =3D> no no, I don't mean it literally, I mean that the message >>>>>> doesn't do anything, i.e. Has no benefit. >>>>>>=20 >>>>>>>=20 >>>>>>> Speaking about benefits, everybody who knows the area is capable >>>>>>> of turning things up side down. I assume it is subjective >>>>>>> standpoint of considering things as benefits or disadvantages and >>>>>>> all is about to agree or disagree. >>>>>>=20 >>>>>> =3D> That's fine, I'm asking for benefits in your opinion not >>>>>> someone else's. >>>>>> It's impossible to discuss this if I can't see any benefits >>>>>> because you didn't send any. What you sent were actions that can >>>>>> be done by the HA and I responded by saying that the same (or >>>>>> more) information is available to the MN. Therefore, if you think >>>>>> there are additional benefits to doing this in the HA then you need = to >>>>>> tell us. >>>>>>=20 >>>>>> The bottom line is this: MIP works by letting the MN install >>>>>> bindings in the HA. If you want things to work in reverse you need >>>>>> to justify it. I can't see any justifications because you're not >>>>>> answering my questions on your scenarios. So, count me out on the >>>>>> reverse direction :). >>>>>>=20 >>>>>>=20 >>>>>> For >>>>>>> me those I wrote about are benefits or potential benefits if you wa= nt. >>>>>>=20 >>>>>> =3D> No you didn't. You wrote about things that can be done. Many >>>>>> things can be done by many entities, the question is why the HA >>>>>> and not the MN. >>>>>>=20 >>>>>>> One important thing in the discussion, although mentioned, but >>>>>>> forgotten later is that by making rules distribution one way >>>>>>> only, we do create limitation for benefits, or potential benefits >>>>>>> if this sounds better. >>>>>>=20 >>>>>> =3D> Well, we won't know what we're missing unless someone tells us. >>>>>> So far no one has mentioned the advantages of doing things in the >>>>>> reverse direction. >>>>>> There is always something missing from a protocol (it's >>>>>> engineering), the question us whether it's significant or worth >>>>>> the trouble. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>>=20 >>>>>>> /yuri >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>> Sent: Wednesday, June 03, 2009 10:10 AM >>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>> Cc: mext@ietf.org >>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>> of flowbindings >>>>>>>=20 >>>>>>> Yuri, >>>>>>>=20 >>>>>>> I can't parse those events you refer to. I'l answer both emails her= e. >>>>>>> First the events you refer to: >>>>>>>=20 >>>>>>>>> - network condition towards CN(s) >>>>>>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>>>>>=20 >>>>>>> =3D> What's the event? A change in those conditions? The MN knows >>>>>>> the conditions of the e2e path as well as or better than the HA. >>>>>>> What is the benefit of having the HA send a hint and how reliable >>>>>>> is that hint anyway? >>>>>>>=20 >>>>>>>>> - Access provider (any access, not necessarily wireless) who >>>>>>>>> offeres HA services preferences change >>>>>>>=20 >>>>>>> =3D> Preferences change to what?? How does it know if such change >>>>>>> works for the MN at all? This is way too vague to be able to >>>>>>> discuss tradeoffs. >>>>>>>=20 >>>>>>>>> - Change of the access provider traffic to another backbone >>>>>>>>> provider due to the time of the day. >>>>>>>>> - Traffic condition on HA interface, which accepts traffic from >>>>>>>>> MN if MN sends on some particular local interface >>>>>>>=20 >>>>>>> =3D> These are path changes. The HA has _no idea_ how such a change >>>>>>> affects each MN/CN combination and it's "hint" can cause more >>>>>>> problems than it solves. BTW, if you're talking about hints then >>>>>>> we're no longer talking about installing bindings in the MN. This >>>>>>> is a different topic. MIP doesn't transfer hints, it pretty much >>>>>>> sends "orders" >>>>>>> from one end to another. >>>>>>>=20 >>>>>>> Now to the actions required by the MN: >>>>>>>=20 >>>>>>>> - reject, >>>>>>>> - re-evaluate and reject >>>>>>>> - re-evaluate and accept >>>>>>>> - accept >>>>>>>=20 >>>>>>> =3D> First, by assuming that the MN can reject the "hint" as you >>>>>>> call it you invalidate the whole argument for the HA to install rul= es. >>>>>>> Rejecting a hint or even evaluating it means that the MN knows more= . >>>>>>> Therefore, the HA's hint is a complete waste of bandwidth. >>>>>>>=20 >>>>>>> I'm still confused about the _benefits_ you see here. Or are you >>>>>>> assuming that the MN can't know those hints without the HA's >>>>>>> involvement? But if you're assuming that, then how can it reject >>>>>>> the hints? This whole proposal makes no sense to me at all. Not >>>>>>> to mention the complexity you implicitly assume in order to >>>>>>> generate those, hopefully reliable, hints. >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>=20 >>>>>>> On 3/06/09 5:23 PM, "Yuri Ismailov" wr= ote: >>>>>>>=20 >>>>>>>> Hesham, >>>>>>>>=20 >>>>>>>> In my view these are events not scenarious. These events are >>>>>>>> known by HA but not MN. If HA acts upon events, given that it >>>>>>>> knows somewhat more about MN, not only IP addresses, it (HA) can >>>>>>>> generate new rules and send them as hint to MN. Back again, MN >>>>>>>> has four >>>>>>>> options: >>>>>>>>=20 >>>>>>>> The benefit will be obviously that the new rules (if accepted) >>>>>>>> may llead to a better overall communication characteristics. >>>>>>>>=20 >>>>>>>> /yuri >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =3D> I'm trying to understand what you mean above. These are all >>>>>>>> scenarios, the question is: What is the benefit for the HA to >>>>>>>> transfer rules? The HA will not know the path between the MN and >>>>>>>> CN more than either node does. So I don't understand what >>>>>>>> _benefits_ you see here. >>>>>>>>=20 >>>>>>>> Hesham >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Pretty much sure that there are more examples and I encourage >>>>>>>>> to think about those not from MN point of view but rather from >>>>>>>>> the HA service provider. >>>>>>>>>=20 >>>>>>>>> /yuri >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>> Cc: mext@ietf.org >>>>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>>>> of flowbindings >>>>>>>>>=20 >>>>>>>>> Yuri, >>>>>>>>>=20 >>>>>>>>> It is just rules TRANSFER which is the matter of MIP. So where >>>>>>>>>> is the logic when saying that MN to HA rules transfer is a >>>>>>>>>> practical engineering and HA to MN is an academic interest? >>>>>>>>>=20 >>>>>>>>> =3D> I think we've (I'm including myself) highlighted several >>>>>>>>> reasons for why it makes little sense to transfer rules from HA t= o MN. >>>>>>>>> Instead of rat-holing on theory Vs practice, you (or others >>>>>>>>> advocating the other direction) need to come up with reasons >>>>>>>>> for doing things this way. This way we can think like engineers >>>>>>>>> about tradeoffs. >>>>>>>>> Absent that, I don't see any point in having theory Vs practice >>>>>>>>> high level discussions, which will lead nowhere. >>>>>>>>>=20 >>>>>>>>> Hesham >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Regards >>>>>>>>>> Yuri >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>>>>>> Subject: Re: [MEXT] Important considerations for >>>>>>>>>> directionality of flowbindings >>>>>>>>>>=20 >>>>>>>>>> Hi Pierrick, >>>>>>>>>>=20 >>>>>>>>>> On Jun 2, 2009, at 4:11 PM, >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Hi all, >>>>>>>>>>>=20 >>>>>>>>>>> Please see inline comment. >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>> Pierrick >>>>>>>>>>>=20 >>>>>>>>>>>> ________________________________________ >>>>>>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De >>>>>>>>>>>> la part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0= : >>>>>>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important >>>>>>>>>>>> considerations for directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham, >>>>>>>>>>>> This is nice story and makes some sense for the discssion, >>>>>>>>>>>> however some details are ommited. In your adventure with the >>>>>>>>>>>> helpdesk, it (the >>>>>>>>>>>> helpdesk) is a third party service and thus your conclusions >>>>>>>>>>>> make sence. >>>>>>>>>>>> Think of the situation when superior of a heldesk person >>>>>>>>>>>> will tell him/her to check access point in some room. Would >>>>>>>>>>>> it be the same reaction? I assume not. By that I mean that >>>>>>>>>>>> if, for example, I'll install home agent in my home network, >>>>>>>>>>>> I can make it know anything I want about MN, and more >>>>>>>>>>>> intresting is that how I will do it, does not require any >>>>>>>>>>>> standardization. >>>>>>>>>>>> In other words, I'm superior of my HA. >>>>>>>>>>>> This situation is not unthinkable, I personally believe that >>>>>>>>>>>> this is much more efficient way of using HA fnctionality as >>>>>>>>>>>> opposed to big service providers who will have to fight with >>>>>>>>>>>> scalability and performance. >>>>>>>>>>>> However, one does not exclude another. >>>>>>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> The difference between policy and rules is not only a matter >>>>>>>>>>> of conversion. A policy, is a static, or quasi-static, set of >>>>>>>>>>> guidance for the MN (e.g use access network X for application >>>>>>>>>>> type >>>>>>>>>>> A,...) while a rule update requires to be more dynamic. I mean: >>>>>>>>>>> eventually a policy could be updated depending on network >>>>>>>>>>> condition (e.g if X overloaded, use access network Y for >>>>>>>>>>> application type A,...) but a rule reacts on local triggers (e.= g. >>>>>>>>>>> modification of the radio link >>>>>>>>>>> quality) with a shorter period of variation. So, IMHO, there >>>>>>>>>>> is no requirement for updating policy on a short period and >>>>>>>>>>> out-of-band mechanism can be used (e.g. IEEE 802.21 in push >>>>>>>>>>> mode,...). >>>>>>>>>>=20 >>>>>>>>>> Fully agree! >>>>>>>>>> This is why I do not support the exchange of rules from the HA >>>>>>>>>> to the MN. >>>>>>>>>> Policies may be exchanged from the HA to the MN, but MIP is >>>>>>>>>> definitely not the protocol to transport them. >>>>>>>>>>=20 >>>>>>>>>> Nicolas >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> My 2 cents... >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Is there any reason to restrict where such convertion takes pl= ace? >>>>>>>>>>>> True >>>>>>>>>>>> that a HA does not know what is going on in the access >>>>>>>>>>>> network, on the other hand HA may know what is the network >>>>>>>>>>>> condition between HA and correspondent node. Either of this >>>>>>>>>>>> information is important, if not equally important. >>>>>>>>>>>> It is not really difficult to let an MN to reject rules sent >>>>>>>>>>>> by HA, which in my view would be quite natural. This implies >>>>>>>>>>>> that HA must follow the rules installed by MN until explicit >>>>>>>>>>>> acceptance has been received from MN. >>>>>>>>>>>> Such procedure is very similar to an MN beahviour when >>>>>>>>>>>> initiating new BU, where MN is not supposed to send any >>>>>>>>>>>> traffic before BU confirmation. >>>>>>>>>>>> BTW, what is the numerical representation of "rough consensus"= ? >>>>>>>>>>>> I assume is when majority is for, is it so? >>>>>>>>>>>> Yuri >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] >>>>>>>>>>>> On Behalf Of Hesham Soliman >>>>>>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>>>>>> To: mext >>>>>>>>>>>> Subject: [MEXT] Important considerations for directionality >>>>>>>>>>>> of flow bindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>> I've always been a fan of the IETF's tradition of rough >>>>>>>>>>>> concensus (as opposed to voting). To me, this implies that >>>>>>>>>>>> you need to get your point across and get other people to >>>>>>>>>>>> see that point of view. >>>>>>>>>>>> As opposed to other organisations that require their members >>>>>>>>>>>> to vote and end up with rigid political positions. >>>>>>>>>>>>=20 >>>>>>>>>>>> The chairs asked us about the directionality question of the >>>>>>>>>>>> flows bindings. >>>>>>>>>>>> On the charter question, I said that the charter doesn't >>>>>>>>>>>> need to mention how a solution should work, but rather what >>>>>>>>>>>> problem needs to be solved. >>>>>>>>>>>> Hence, as far as the charter is concerned, I'm fine with >>>>>>>>>>>> transferring rules "between" the MN and HA without >>>>>>>>>>>> mentioning directions. >>>>>>>>>>>>=20 >>>>>>>>>>>> Nevertheless, we still need to agree on identifying the >>>>>>>>>>>> requirement for the solution. And when it comes to this, I'm >>>>>>>>>>>> strongly against voting and I'll practice this by explaining >>>>>>>>>>>> in this email why I think rules can not be transferred from >>>>>>>>>>>> the HA to the MN and that the only direction that makes >>>>>>>>>>>> sense in MIP is >>>>>>>>>>>> MN->HA. I'll deliberately ignore arguments like "some people >>>>>>>>>>>> MN->want >>>>>>>>>>>> this" or "an SDO wants this". They fall under the >>>>>>>>>>>> "meaningless words" >>>>>>>>>>>> category and I'm incapable of discussing them because they >>>>>>>>>>>> come with voting attitudes. They all need to be justified if >>>>>>>>>>>> the WG wants to have a technical _discussion_. >>>>>>>>>>>>=20 >>>>>>>>>>>> Here are my reasons: >>>>>>>>>>>>=20 >>>>>>>>>>>> 1. The HA does not know whether a CoA is tied to a certain >>>>>>>>>>>> access technology. It is one thing for the HA to send a >>>>>>>>>>>> message saying "forward port 80 traffic on a wifi link" (a >>>>>>>>>>>> policy) and a completely different thing to say "forward >>>>>>>>>>>> port 80 traffic using CoA 3ffe::1" >>>>>>>>>>>> (a rule). >>>>>>>>>>>>=20 >>>>>>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem now? >>>>>>>>>>>> The problem is that the HA has no idea about dynamic changes >>>>>>>>>>>> on that wifi link. It doesn't know if it's congested, it >>>>>>>>>>>> doesn't know what application is using port 80 (it doesn't=20 >>>>>>>>>>>> have to be web >>>>>>>>>>>> traffic) or port 8000 for that matter and doesn't even know=20 >>>>>>>>>>>> if the AP of that wifi link works at all. >>>>>>>>>>>> Finally, it >>>>>>>>>>>> doesn't know the user's policies or other admin policies for=20 >>>>>>>>>>>> that MN. >>>>>>>>>>>> This type of information needs to be sent regularly because=20 >>>>>>>>>>>> it changes all the time and requires serious cross layer=20 >>>>>>>>>>>> integration including sometimes layer 8 integration! It's=20 >>>>>>>>>>>> completely impractical. >>>>>>>>>>>>=20 >>>>>>>>>>>> 3. If the HA installed rules in the MN, what happens if the=20 >>>>>>>>>>>> MN wants to change those rules. Say the wifi link went down,=20 >>>>>>>>>>>> or the MN's wifi interface went down and it wants to move=20 >>>>>>>>>>>> that traffic to another interface. Would the HA reject such mo= ve? >>>>>>>>>>>> Does the MN have to justify to the HA why it needs to move=20 >>>>>>>>>>>> traffic? Does that involve writing a letter perhaps? >>>>>>>>>>>> If you say "well in that case, the HA should let the MN move=20 >>>>>>>>>>>> the traffic" >>>>>>>>>>>> then I'll ask you: what's the point of having the HA install=20 >>>>>>>>>>>> this stuff if it has no authority and how does it know the=20 >>>>>>>>>>>> reason for the MN's movement of the flow? >>>>>>>>>>>> The way to control how users do things is to incentivise=20 >>>>>>>>>>>> them with charging models and show them that things work=20 >>>>>>>>>>>> better on certain technologies, not by installing rules that=20 >>>>>>>>>>>> can't be followed. It's a broken mindset and we've known=20 >>>>>>>>>>>> that it's broken for a long time. >>>>>>>>>>>>=20 >>>>>>>>>>>> 4. Some people mentioned that the HA should be able to=20 >>>>>>>>>>>> revoke flows on the MN. I'm perfectly fine with that, just=20 >>>>>>>>>>>> extend the binding revocation draft to handle flows and the=20 >>>>>>>>>>>> rest is pretty straight forward. >>>>>>>>>>>>=20 >>>>>>>>>>>> Finally, I'll indulge in a true story that happened to me a=20 >>>>>>>>>>>> few years ago when I found that my wifi link wasn't working=20 >>>>>>>>>>>> in a hotel (no >>>>>>>>>>>> radio) >>>>>>>>>>>> and called the help desk. He insisted that the link was up=20 >>>>>>>>>>>> an I insisted that it wasn't. When I asked him to tell me=20 >>>>>>>>>>>> how he knows the link is up he said: I can ping the AP! Of=20 >>>>>>>>>>>> course after another >>>>>>>>>>>> 5 minutes of trying to convince him that pinging the AP=20 >>>>>>>>>>>> doesn't mean the radio is actually working he sent someone=20 >>>>>>>>>>>> to the hotel who in turn realised that the radio was not worki= ng. >>>>>>>>>>>> For those people who want rules to be transferred from the=20 >>>>>>>>>>>> HA to the MN, please think of your HA as this help desk person= ,=20 >>>>>>>>>>>> i.e. >>>>>>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>>>>>=20 >>>>>>>>>>>> I hope this helps with the realisation that decisions can't=20 >>>>>>>>>>>> be made here based on voting and that there is little merit=20 >>>>>>>>>>>> to transferring rules from the HA to the MN. Policies can be=20 >>>>>>>>>>>> transferred without any problems, but not rules. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> MEXT mailing list >>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From behcetsarikaya@yahoo.com Fri Jun 5 09:27:22 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1103F3A6DE8 for ; Fri, 5 Jun 2009 09:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.804 X-Spam-Level: X-Spam-Status: No, score=-2.804 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 QhsPjlhVa7tz for ; Fri, 5 Jun 2009 09:27:18 -0700 (PDT) Received: from n79.bullet.mail.sp1.yahoo.com (n79.bullet.mail.sp1.yahoo.com [98.136.44.39]) by core3.amsl.com (Postfix) with SMTP id AAEF73A6DD6 for ; Fri, 5 Jun 2009 09:27:18 -0700 (PDT) Received: from [216.252.122.216] by n79.bullet.mail.sp1.yahoo.com with NNFMP; 05 Jun 2009 16:27:20 -0000 Received: from [67.195.9.81] by t1.bullet.sp1.yahoo.com with NNFMP; 05 Jun 2009 16:27:20 -0000 Received: from [67.195.9.106] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 05 Jun 2009 16:27:19 -0000 Received: from [127.0.0.1] by omp110.mail.gq1.yahoo.com with NNFMP; 05 Jun 2009 16:25:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 245110.31337.bm@omp110.mail.gq1.yahoo.com Received: (qmail 347 invoked by uid 60001); 5 Jun 2009 16:27:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1244219239; bh=6AnpRU6VfGBXTLwhX1h2meBrm9okVhCPK5J5WkdtRxE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4ZQWguHgG6EX+0YeyexzCi8lS/1QRDQH6nBzXptSqx26N/PnWOZcvZ87NHqWqxuZE267sFFKvjaoxITMSmqclFjN8x4FiCKEVZT5Y/uE4gGxo5tIjgxEE0ue+RZ8TUTLHl+WSbmB0TEW7SXnhyGL5gfP70ZWHf9VTmXQBCyY5Uc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=dhl51JaHxwQtJy3vZcmUeJ31e0Yf2IJUmyIysfJR2Ggxc66BjKftpwp5+tFlIq7w0TMaf+31v6MQpjxZGDnYdOfiVfmBEMwLl55wlv2LHzuXKcwzQAKA6j0uJdSRz2OH2y5g0grh/8+dqvGPKWS3dPTQavTQ0TPc+sOu8ZtgQuw=; Message-ID: <683217.323.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: YAzSG.gVM1kduPNtDdahyJ19zFlDl8NIFzi1vklOkChvxC1zlzuMGIXKUsJoi8FhcBTjY.5Ml8K_NBUDOEwPwkXw6eA9x1n7Y8Mxif1LcWqR4lizu9yUH_aA59ucnuPN.eXjmnwviV_KO8FIpuLWDT285qYKkfG5uBnQkQDVblJ.1S8mhsj7GT1Ym7ha6dhhjS8Kwh.m8r6UFjGrkailUZyH4PsLFtzFOvxVWs3TQ2RSS.GlZWhFkR5iAgf0TMrrfmSltoVEvp6ximrcVQe0CBDn8s5PElCvbaY00I8dC7RWWXgLfBQlwowORYJUS3gAvDh_IJUv Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Fri, 05 Jun 2009 09:27:19 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 References: Date: Fri, 5 Jun 2009 09:27:19 -0700 (PDT) From: Behcet Sarikaya To: Yuri Ismailov In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 16:27:22 -0000 Hi Yuri,=0A=A0 I agree with all of your assumptions, I think they are all r= elevant to flow mobility discussions.=0A=A0 However in order to have some p= rogress, I would like to know the results of Marcelo's poll. I would like t= o see people stop questioning the charter, esp. no HA to MN flow binding, e= tc..=0A=A0 Once that is done, I think the next thing is to discuss on a spe= cific draft which gives a solution to HA to MN flow binding.=0A=0ARegards,= =0A=0ABehcet=0A=0A=0A=0A----- Original Message ----=0AFrom: Yuri Ismailov <= yuri.ismailov@ericsson.com>=0ATo: Hesham Soliman = ; Nicolas Montavont ; pierrick.seite@orange-ftgroup.com= =0ACc: mext@ietf.org=0ASent: Friday, June 5, 2009 7:46:37 AM=0ASubject: Re:= [MEXT] Important considerations for directionality of flowbindings=0A=0AHe= sham,=0A=0ALet's proceed with sorting out what we are talking about, this p= robably will help structuring examples and scenarious=0A=0AMy assumptions: = (probably shuold have been mentioned earlier)=0AIf we will agree on assumpt= ions, then it will make sense to go further on.=0A=0AFirst is that I assume= that we have simulteneous multiaccess in mind, i.e. MN has more than one i= nterface to choose from for its flows. If this is not the case then I will = stop the discussion. This assumption is based on the fact that we are (I ho= pe at least) discussing flow mobility.=0A=0ASecondly, I consider that MN ch= ooses an interface but not CoA. I gave a though about that and did not come= up with any information which can be derived from CoA in order to choose i= t. An interface has at least expected characteristics, thus can be a subjec= t of choice. Any clarification about that would be appreciated.=0A=0ANext a= ssumptions are about possible configurations of HA=0A- Single HA for all in= terfaces configured in the mobile. HA can belong to any of the access provi= ders of each of access technology used by MN.=0A=0A- One HA per access or s= et of accesses, which is subset of all access techologies presented or pote= ntially may be presented (detached devices) in MN.=0AAnticipating numerous = questions about that can say that I looked at such configuration and did no= t find anything strange with it, i.e. (1) it works, (2) it does not require= any change to MIP or any other of its extensions. (3) Configuration is per= formed per interface and does not introduce any ambiguities. (4) it is natu= ral for access provider to offer HA service.=0A=0A- "Residential" HA. Assum= ption is that it can be either one of HA's or a single HA for all types of = accesses. This is the matter of MN configuration.=0A"Residential".=0A=0A- A= ny HA may have multiple interfaces, e.g. "residential" HA may be connected = to mobile broadband, DSL, etc.=0A=0ANext assumption comes from the example = (e.g. latest one)=0A- Traffic shaping is applied in both directions (up/dow= n) link (in practice this is the case).=0A- Traffic shaping (TS) is applied= to user subscription. In other words TS is applied to packets belonging to= a particular subscription but not to an aggregated traffic on gateway inte= rfaces. HA is not necessary (however, nothing prevents from that) a gateway= where TS is applied.=0A=0A=0AI hope that I have not missed something, alth= ough it may be possible.=0AIf we can agree on that or correct if something = is wrong here and agree later then we know how to proceed further on=0A=0A/= yuri=0A=0A=0A-----Original Message-----=0AFrom: Hesham Soliman [mailto:hesh= am@elevatemobile.com] =0ASent: Friday, June 05, 2009 11:37 AM=0ATo: Yuri Is= mailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com=0ACc: mext@iet= f.org=0ASubject: Re: [MEXT] Important considerations for directionality of = flowbindings=0A=0AYuri,=0A=0A=0A> Still not clear for me why you call scena= rious invalid?=0A> Some broadband providers (this is used in practice) have= quota on the =0A> amount of traffic sent by users. Once quota is exceeded = provider =0A> downgardes outgoing traffic from its network to 64Kbs (this f= igure is =0A> the real example from real provider). Such combination of to = paths, =0A> where one is high speed, lets say 10 Mbs and another one is 64K= bs is quite crusual to apps running on top of TCP.=0A> Not for all types of= traffic though.=0A=0A=3D> Yes I know the scenario but I keep saying to you= that the change in upstream routing in the HA has nothing to do with CoA s= election by the MN in the visited network. If anything, you want the MN to = change it's HoA depending on how the switch to another upstream ISP works. = It's a completely irrelevant issue to this discussion. Do you agree? If not= why not? I really want to see an answer to this point.=0A=0A=0A=0A=0A> =0A= > MN can not know about this situation. Nobody will send this information t= o MN.=0A=0A=3D> Yes and if it knows what will it do??? If you can answer th= at you will fix the deadlock we have.=0A=0A> That means that MN will choose= its interfaces based on its knowledge =0A> about 10Mbs link capabilities.= =0A=0A=3D> You're talking about two different things. The MN doesn't choose= the HA's outgoing interface! What am I missing?=0A=0AObtaining this isnfor= mation from HA is quite=0A> significant to make a better decision about cho= ice of interfaces for =0A> its flows.=0A>=A0 This is concrete example of wh= at happens in the reality.=0A> Do you consider that this information will b= e useless for MN?=0A=0A=3D> Completely useless. Unless I'm missing somethin= g in your scenario. Just write down step by step what will happen and inclu= de messages. I don't see how this can possibly be relevant to the MN.=0A=0A= Hesham=0A=0AHesham=0A=0A> =0A> /yuri=0A> =0A> =0A> -----Original Message---= --=0A> From: Hesham Soliman [mailto:hesham@elevatemobile.com]=0A> Sent: Thu= rsday, June 04, 2009 4:38 PM=0A> To: Yuri Ismailov; Nicolas Montavont; =0A>= pierrick.seite@orange-ftgroup.com=0A> Cc: mext@ietf.org=0A> Subject: Re: [= MEXT] Important considerations for directionality of =0A> flowbindings=0A> = =0A> Yuri,=0A> =0A> =0A> On 5/06/09 12:01 AM, "Yuri Ismailov" wrote:=0A> =0A>> Hesham,=0A>> =0A>> I provided several scen= arious which you said are invalid. This is =0A>> where my conclusion about = standpoint comes from.=0A>> Whether you call hints policies or rules it doe= s not change what =0A>> information can be provided by HA to MN.=0A> =0A> = =3D> It changes the outcome for the work item we're discussing. I'm =0A> tr= ying to come to a conclusion on this and there is a huge difference =0A> be= tween transferring policies and installing flow bindings.=0A> =0A>> By send= ing rules HA does not install anything in MN. Likewise, MN =0A>> does not i= nstall rules in HA, it informs HA about currently made choices.=0A>> As I r= emember rules will not be valid until proper Ack arrival, which =0A>> for m= e means that may not be instantiated at all.=0A>> Niether rules nor polices= are specific to MIP. As I wrote those can =0A>> be exchanged between hosts= without any MIP implementation, just for =0A>> access selection purposes. = Once it was decided to make it as part of =0A>> MIP protocol, I'm fine with= that. Do not have any idea to discuss =0A>> this, while personally conside= r that the work on rules transfer can =0A>> very well fit into the MEXT gro= up but as a separate work item, but =0A>> this is not the case now, so good= enough the way it is.=0A>> And back again, it really gets repeated, so wil= l lead to nowhere, =0A>> you've got my arguments and tell that the informat= ion, which I'm =0A>> talking about, is not usefull. What can I say more? I = can put you on =0A>> my position and start asking questions instead of answ= ering. So, why =0A>> it is not usefull?=0A> =0A> =3D> I explained why the s= pecific information you mentioned was not =0A> useful/useable by the MN and= this is what I referred to as unanswered.=0A> Because if you agree with my= previous explanations then we don't need =0A> to discuss it further. If yo= u disagree you certainly didn't tell me =0A> why. You have the charge of pr= oof because you want to change the way =0A> MIP works currently, that's all= I'm trying to say.=0A> =0A> Hesham=0A> =0A>> =0A>> /yuri=0A>> =0A>> =0A>> = -----Original Message-----=0A>> From: Hesham Soliman [mailto:hesham@elevate= mobile.com]=0A>> Sent: Thursday, June 04, 2009 4:00 AM=0A>> To: Yuri Ismail= ov; Nicolas Montavont; =0A>> pierrick.seite@orange-ftgroup.com=0A>> Cc: mex= t@ietf.org=0A>> Subject: Re: [MEXT] Important considerations for directiona= lity of =0A>> flowbindings=0A>> =0A>> Yuri,=0A>> =0A>> =0A>> =0A>>> Missing= is additional information which may be helpful in making =0A>>> better dec= ision about interface selection by MN.=0A>>> Which information is that I wr= ote in my previous emails. Back to my =0A>>> examples (not all, do not want= to repeat myself). If HA will have =0A>>> changed traffic shaping paramete= rs on one of the incoming or =0A>>> outgoing interfaces, this will be impor= tant information for MN to know.=0A>>> We have agreed already that whether = this information important or =0A>>> not, benfitial or not is a matter of s= tandpoint.=0A>> =0A>> =3D> I don't agree or like to think that it's a matte= r of standpoint.=0A>> That's why I asked you on every point you raised and = compared this to =0A>> the MN's knowledge on e2e basis. Once we have "stand= points" then =0A>> we're getting outside the technical realm. The reason I = don't think =0A>> it's useful is that this information cannot be used by th= e MN to =0A>> select a CoA. I've already stated that before and you seemed = to agree =0A>> so I don't know why you repeat this as a reason for the HA t= o install =0A>> filters in the MN. Let me say it=0A>> again: There is no co= rrelation between the routing on the HA's =0A>> upstream interfaces/ISP wit= h the MN's selection of a CoA.=0A>> =0A>>> I consider that knowing more is = a benefit and will help to get =0A>>> better result.=0A>>> =0A>>> My point = is still the same. I see the reverse rules sending as =0A>>> possibility to= provide more information to the MN, thus make MN to =0A>>> get to better d= ecision about interface selection for its flows. This =0A>>> point has not = changed since the beginning of the discussion.=0A>> =0A>> =3D> This is why = we're not making progress IMO:=0A>> =0A>> 1. The hints you refer to are not= the same things as installing rules =0A>> on the MN. Completely different = information in fact. You've =0A>> essentially proved that when you suggeste= d that the MN can accept or =0A>> reject them. So, let's not call them rule= s. The more direct word for =0A>> what you want to send is policies=0A>> = =0A>> 2. You didn't provide a valid scenario that we can discuss as to why = =0A>> it's needed or how it could work. I've asked numerous questions in = =0A>> each email that were not answered (with the exception of the last =0A= >> email). It's not possible to progress the discussion without =0A>> answe= ring each others'=0A>> questions. You can go back through the threads and v= erify this.=0A>> =0A>> 3. If we're sending rules from the HA to the MN and = the MN can reject =0A>> those rules then the whole exercise is pointless. Y= ou really want to =0A>> send policies not rules. I can imagine those polici= es being one of =0A>> the inputs that the MN uses to make a decision. I sti= ll fail to see =0A>> how anything happening on the HA's upstream interfaces= /ISP link can =0A>> possibly influence the MN's decision for CoA selection.= This is =0A>> another unanswered question.=0A>> =0A>> Hesham=0A>> =0A>>> = =0A>>> /yuri=0A>>> =0A>>> -----Original Message-----=0A>>> From: Hesham Sol= iman [mailto:hesham@elevatemobile.com]=0A>>> Sent: Wednesday, June 03, 2009= 4:09 PM=0A>>> To: Yuri Ismailov; Nicolas Montavont; =0A>>> pierrick.seite@= orange-ftgroup.com=0A>>> Cc: mext@ietf.org=0A>>> Subject: Re: [MEXT] Import= ant considerations for directionality of =0A>>> flowbindings=0A>>> =0A>>> = =0A>>> =0A>>> =0A>>> On 3/06/09 10:47 PM, "Yuri Ismailov" wrote:=0A>>> =0A>>>> Ok, see your point, however:-)=0A>>>> =0A>= >>> The major difference here is that your are talking about CoA =0A>>>> se= lection and I'm talking about interface selection. Quite a big =0A>>>> diff= erence.=0A>>> =0A>>> =3D> No, that's not the point really. The point is tha= t there is no =0A>>> relationship between CoA/interface selection on the MN= and the =0A>>> upstream ISP for the home network.=0A>>> =0A>>>> I do not s= ee any grounds for MN to select CoA, based on what? =0A>>>> Prefix length?= =0A>>>> While selection of an interface is based on expected =0A>>>> charac= teristics of the communication. Routes (up/down)link in my =0A>>>> opinion = do have impact on the characteristics and this is exactly =0A>>>> the infor= mation missing in the MN when selecting interface.=0A>>> =0A>>> =3D> There = is nothing missing for the MN to make this selection. =0A>>> Please tell us= specifically what is missing. You're changing points =0A>>> on me all the = time now.=0A>>> Lets stick to one point at a time. What's missing?=0A>>> = =0A>>>> =0A>>>> Whenever, MN decides to move a flow, the reason can be anyt= hing but =0A>>>> not which CoA it has configured on each interface.=0A>>>> = =0A>>>> Another thing is that MN will notice something e2e if and only if = =0A>>>> such support is implemented in the MN.=0A>>> =0A>>> =3D> Of course,= so what?=0A>>> =0A>>>=A0 Moreover, this notice can not be made at IP layer= ..=0A>>>> TCP fights alone with all problems and never tells to any other = =0A>>>> layer what is going on. So what is left? Two options. Add this =0A>= >>> support to operating system, which makes its (support) existence =0A>>>= > questionable, or to applications, which is even more questionable.=0A>>> = =0A>>> =3D> It's interesting that you think it's questionable to add the = =0A>>> support to the MN's OS but not questionable to add the support to = =0A>>> the HA's OS, which will not lead to the same reliability as if it = =0A>>> were done in the MN. It doesn't make sense to me.=0A>>> =0A>>>> =0A>= >>>>> =0A>>>>>> Well, that's debatable, but this is clearly not a reason to= do anything.=0A>>>>>> =0A>>>> Are you serious about that MIP may be broken= because of that?=0A>>> =0A>>> =3D> Yes! It's not designed to do what you w= ant to do. Luckily, in =0A>>> this case what you want, IMO, is broken anywa= y so it's not a problem.=0A>>> =0A>>> Hesham=0A>>> =0A>>>> =0A>>>> /yuri=0A= >>>> =0A>>>> =0A>>>> -----Original Message-----=0A>>>> From: Hesham Soliman= [mailto:hesham@elevatemobile.com]=0A>>>> Sent: Wednesday, June 03, 2009 1:= 15 PM=0A>>>> To: Yuri Ismailov; Nicolas Montavont; =0A>>>> pierrick.seite@o= range-ftgroup.com=0A>>>> Cc: mext@ietf.org=0A>>>> Subject: Re: [MEXT] Impor= tant considerations for directionality of =0A>>>> flowbindings=0A>>>> =0A>>= >> =0A>>>> =0A>>>>> =0A>>>>> Still some answers, despite knowing that in yo= ur opinion they are =0A>>>>> not benefits.=0A>>>>> =0A>>>>> First of all MI= P will not be breaked if the rules will be sent in =0A>>>>> both directions= ..=0A>>>> =0A>>>> =3D> Well, that's debatable, but this is clearly not a rea= son to do anything.=0A>>>> =0A>>>>> =0A>>>>> - Access provider preferences = relate to the use of backbone =0A>>>>> provider, which may vary with the ti= me of day. Changing backbone =0A>>>>> provider can make quite big differenc= e for commnication between HA =0A>>>>> (if HA service is provided by the sa= me access provider) and CN(s).=0A>>>>> The difference can be expressed in, = let's say, number of hops, =0A>>>>> load, possibly something else. Such cha= nge is an event and may =0A>>>>> have an impact on the overall communicatio= n. This can be told =0A>>>>> directly to MN or HA. Direct communication to = MN (if accepted as =0A>>>>> benefit:-)) in such case will need standardizat= ion. Communication =0A>>>>> of this information to HA does not (I consider = this as a benefit). =0A>>>>> HA may act upon that event, and the rest you= =0A>>>>> know: rules in reverse direction.=0A>>>> =0A>>>> =3D> There is no = need to _tell_ the MN anything. There are two issues here.=0A>>>> First, ch= anging network conditions are best known e2e. So the MN =0A>>>> will know t= hat anyway based on the traffic running between it and the CN.=0A>>>> The o= ther issue is related to cost for certain times of day. This =0A>>>> is a r= outing issue in the HA and has nothing to do with which =0A>>>> interface t= he MN selects. The selected CoA has zero impact on the =0A>>>> HA's upstrea= m selection. Completely irrelevant actually.=0A>>>> Of course, as far as co= st on the visited link, the MN knows best.=0A>>>> =0A>>>>> =0A>>>>> - Acces= s provider may set up different parameters for traffic =0A>>>>> shaping for= each of HA interfaces. These preferences may vary =0A>>>>> independently o= f change of backbone provider but dependently on =0A>>>>> the time of day.= =0A>>>>> The rest you know, whether it changes somebodies opinion.=0A>>>> = =0A>>>> =3D> But again, this has zero effect on CoA selection. The two issu= es =0A>>>> are completely orthogonal. Selecting CoA1 or CoA2 has zero impac= t =0A>>>> on the HA's upstream route.=0A>>>> =0A>>>>> =0A>>>>> - I presume = that in RO mode this is similar to HA mode, and I'm in =0A>>>>> when it com= es to send rules in reverse direction between CN and MN.=0A>>>>> Benefits o= f doing that is that any change percieved by CN as =0A>>>>> important to re= act upon can be expressed in proposal of new rules.=0A>>>>> The sources cau= sing changes may include but not limited to, are =0A>>>>> user, network man= agemnt events, application generated events, etc.=0A>>>>> =0A>>>>> So feel = free to consider this as benefits or not=0A>>>> =0A>>>> =3D> You seem to th= ink that there is a relationship between upstream =0A>>>> routing and CoA s= election. That's not the case at all. These are =0A>>>> two different addre= sses from two different networks.=0A>>>> =0A>>>> Hesham=0A>>>> =0A>>>>> =0A= >>>>> /yuri=0A>>>>> =0A>>>>> -----Original Message-----=0A>>>>> From: Hesha= m Soliman [mailto:hesham@elevatemobile.com]=0A>>>>> Sent: Wednesday, June 0= 3, 2009 11:47 AM=0A>>>>> To: Yuri Ismailov; Nicolas Montavont; =0A>>>>> pie= rrick.seite@orange-ftgroup.com=0A>>>>> Cc: mext@ietf.org=0A>>>>> Subject: R= e: [MEXT] Important considerations for directionality of =0A>>>>> flowbindi= ngs=0A>>>>> =0A>>>>> =0A>>>>> =0A>>>>> =0A>>>>> On 3/06/09 7:33 PM, "Yuri I= smailov" wrote:=0A>>>>> =0A>>>>>> Hesham,=0A>>= >>>> =0A>>>>>> Whenever we talk about sending additional information, the "= waste =0A>>>>>> of bandwidth" can be brought up. So I do not have an answer= for =0A>>>>>> that besides speculations around it.=0A>>>>> =0A>>>>> =3D> n= o no, I don't mean it literally, I mean that the message =0A>>>>> doesn't d= o anything, i.e. Has no benefit.=0A>>>>> =0A>>>>>> =0A>>>>>> Speaking about= benefits, everybody who knows the area is capable =0A>>>>>> of turning thi= ngs up side down. I assume it is subjective =0A>>>>>> standpoint of conside= ring things as benefits or disadvantages and =0A>>>>>> all is about to agre= e or disagree.=0A>>>>> =0A>>>>> =3D> That's fine, I'm asking for benefits i= n your opinion not =0A>>>>> someone else's.=0A>>>>> It's impossible to disc= uss this if I can't see any benefits =0A>>>>> because you didn't send any. = What you sent were actions that can =0A>>>>> be done by the HA and I respon= ded by saying that the same (or =0A>>>>> more) information is available to = the MN. Therefore, if you think =0A>>>>> there are additional benefits to d= oing this in the HA then you need to tell us.=0A>>>>> =0A>>>>> The bottom l= ine is this: MIP works by letting the MN install =0A>>>>> bindings in the H= A. If you want things to work in reverse you need =0A>>>>> to justify it. I= can't see any justifications because you're not =0A>>>>> answering my ques= tions on your scenarios. So, count me out on the =0A>>>>> reverse direction= :).=0A>>>>> =0A>>>>> =0A>>>>> For=0A>>>>>> me those I wrote about are bene= fits or potential benefits if you want.=0A>>>>> =0A>>>>> =3D> No you didn't= .. You wrote about things that can be done. Many =0A>>>>> things can be done= by many entities, the question is why the HA =0A>>>>> and not the MN.=0A>>= >>> =0A>>>>>> One important thing in the discussion, although mentioned, bu= t =0A>>>>>> forgotten later is that by making rules distribution one way = =0A>>>>>> only, we do create limitation for benefits, or potential benefits= =0A>>>>>> if this sounds better.=0A>>>>> =0A>>>>> =3D> Well, we won't know= what we're missing unless someone tells us.=0A>>>>> So far no one has ment= ioned the advantages of doing things in the =0A>>>>> reverse direction.=0A>= >>>> There is always something missing from a protocol (it's =0A>>>>> engin= eering), the question us whether it's significant or worth =0A>>>>> the tro= uble.=0A>>>>> =0A>>>>> Hesham=0A>>>>> =0A>>>>>> =0A>>>>>> /yuri=0A>>>>>> = =0A>>>>>> =0A>>>>>> =0A>>>>>> -----Original Message-----=0A>>>>>> From: Hes= ham Soliman [mailto:hesham@elevatemobile.com]=0A>>>>>> Sent: Wednesday, Jun= e 03, 2009 10:10 AM=0A>>>>>> To: Yuri Ismailov; Nicolas Montavont; =0A>>>>>= > pierrick.seite@orange-ftgroup.com=0A>>>>>> Cc: mext@ietf.org=0A>>>>>> Sub= ject: Re: [MEXT] Important considerations for directionality =0A>>>>>> of f= lowbindings=0A>>>>>> =0A>>>>>> Yuri,=0A>>>>>> =0A>>>>>> I can't parse those= events you refer to. I'l answer both emails here.=0A>>>>>> First the event= s you refer to:=0A>>>>>> =0A>>>>>>>> - network condition towards CN(s)=0A>>= >>>>>> - the sum of number of hops between MN -> HA and HA -> CN=0A>>>>>> = =0A>>>>>> =3D> What's the event? A change in those conditions? The MN knows= =0A>>>>>> the conditions of the e2e path as well as or better than the HA.= =0A>>>>>> What is the benefit of having the HA send a hint and how reliable= =0A>>>>>> is that hint anyway?=0A>>>>>> =0A>>>>>>>> - Access provider (any= access, not necessarily wireless) who =0A>>>>>>>> offeres HA services pref= erences change=0A>>>>>> =0A>>>>>> =3D> Preferences change to what?? How doe= s it know if such change =0A>>>>>> works for the MN at all? This is way too= vague to be able to =0A>>>>>> discuss tradeoffs.=0A>>>>>> =0A>>>>>>>> - Ch= ange of the access provider traffic to another backbone =0A>>>>>>>> provide= r due to the time of the day.=0A>>>>>>>> - Traffic condition on HA interfac= e, which accepts traffic from =0A>>>>>>>> MN if MN sends on some particular= local interface=0A>>>>>> =0A>>>>>> =3D> These are path changes. The HA has= _no idea_ how such a change =0A>>>>>> affects each MN/CN combination and i= t's "hint" can cause more =0A>>>>>> problems than it solves. BTW, if you're= talking about hints then =0A>>>>>> we're no longer talking about installin= g bindings in the MN. This =0A>>>>>> is a different topic. MIP doesn't tran= sfer hints, it pretty much =0A>>>>>> sends "orders"=0A>>>>>> from one end t= o another.=0A>>>>>> =0A>>>>>> Now to the actions required by the MN:=0A>>>>= >> =0A>>>>>>> - reject,=0A>>>>>>> - re-evaluate and reject=0A>>>>>>> - re-e= valuate and accept=0A>>>>>>> - accept=0A>>>>>> =0A>>>>>> =3D> First, by ass= uming that the MN can reject the "hint" as you =0A>>>>>> call it you invali= date the whole argument for the HA to install rules.=0A>>>>>> Rejecting a h= int or even evaluating it means that the MN knows more.=0A>>>>>> Therefore,= the HA's hint is a complete waste of bandwidth.=0A>>>>>> =0A>>>>>> I'm sti= ll confused about the _benefits_ you see here. Or are you =0A>>>>>> assumin= g that the MN can't know those hints without the HA's =0A>>>>>> involvement= ? But if you're assuming that, then how can it reject =0A>>>>>> the hints? = This whole proposal makes no sense to me at all. Not =0A>>>>>> to mention t= he complexity you implicitly assume in order to =0A>>>>>> generate those, h= opefully reliable, hints.=0A>>>>>> =0A>>>>>> Hesham=0A>>>>>> =0A>>>>>> =0A>= >>>>> On 3/06/09 5:23 PM, "Yuri Ismailov" wrot= e:=0A>>>>>> =0A>>>>>>> Hesham,=0A>>>>>>> =0A>>>>>>> In my view these are ev= ents not scenarious. These events are =0A>>>>>>> known by HA but not MN. If= HA acts upon events, given that it =0A>>>>>>> knows somewhat more about MN= , not only IP addresses, it (HA) can =0A>>>>>>> generate new rules and send= them as hint to MN. Back again, MN =0A>>>>>>> has four=0A>>>>>>> options:= =0A>>>>>>> =0A>>>>>>> The benefit will be obviously that the new rules (if = accepted) =0A>>>>>>> may llead to a better overall communication characteri= stics.=0A>>>>>>> =0A>>>>>>> /yuri=0A>>>>>>> =0A>>>>>>> =0A>>>>>>> =3D> I'm = trying to understand what you mean above. These are all =0A>>>>>>> scenario= s, the question is: What is the benefit for the HA to =0A>>>>>>> transfer r= ules? The HA will not know the path between the MN and =0A>>>>>>> CN more t= han either node does. So I don't understand what =0A>>>>>>> _benefits_ you = see here.=0A>>>>>>> =0A>>>>>>> Hesham=0A>>>>>>> =0A>>>>>>>> =0A>>>>>>>> Pre= tty much sure that there are more examples and I encourage =0A>>>>>>>> to t= hink about those not from MN point of view but rather from =0A>>>>>>>> the = HA service provider.=0A>>>>>>>> =0A>>>>>>>> /yuri=0A>>>>>>>> =0A>>>>>>>> = =0A>>>>>>>> =0A>>>>>>>> =0A>>>>>>>> -----Original Message-----=0A>>>>>>>> F= rom: Hesham Soliman [mailto:hesham@elevatemobile.com]=0A>>>>>>>> Sent: Wedn= esday, June 03, 2009 8:41 AM=0A>>>>>>>> To: Yuri Ismailov; Nicolas Montavon= t; =0A>>>>>>>> pierrick.seite@orange-ftgroup.com=0A>>>>>>>> Cc: mext@ietf.o= rg=0A>>>>>>>> Subject: Re: [MEXT] Important considerations for directionali= ty =0A>>>>>>>> of flowbindings=0A>>>>>>>> =0A>>>>>>>> Yuri,=0A>>>>>>>> =0A>= >>>>>>>=A0 It is just rules TRANSFER which is the matter of MIP. So where= =0A>>>>>>>>> is the logic when saying that MN to HA rules transfer is a =0A= >>>>>>>>> practical engineering and HA to MN is an academic interest?=0A>>>= >>>>> =0A>>>>>>>> =3D> I think we've (I'm including myself) highlighted sev= eral =0A>>>>>>>> reasons for why it makes little sense to transfer rules fr= om HA to MN.=0A>>>>>>>> Instead of rat-holing on theory Vs practice, you (o= r others =0A>>>>>>>> advocating the other direction) need to come up with r= easons =0A>>>>>>>> for doing things this way. This way we can think like en= gineers =0A>>>>>>>> about tradeoffs.=0A>>>>>>>> Absent that, I don't see an= y point in having theory Vs practice =0A>>>>>>>> high level discussions, wh= ich will lead nowhere.=0A>>>>>>>> =0A>>>>>>>> Hesham=0A>>>>>>>> =0A>>>>>>>>= =0A>>>>>>>>> =0A>>>>>>>>> Regards=0A>>>>>>>>> Yuri=0A>>>>>>>>> =0A>>>>>>>>= > -----Original Message-----=0A>>>>>>>>> From: Nicolas Montavont [mailto:ie= tf@montavont.net]=0A>>>>>>>>> Sent: Tuesday, June 02, 2009 5:47 PM=0A>>>>>>= >>> To: pierrick.seite@orange-ftgroup.com=0A>>>>>>>>> Cc: Yuri Ismailov; he= sham@elevatemobile.com; mext@ietf.org=0A>>>>>>>>> Subject: Re: [MEXT] Impor= tant considerations for =0A>>>>>>>>> directionality of flowbindings=0A>>>>>= >>>> =0A>>>>>>>>> Hi Pierrick,=0A>>>>>>>>> =0A>>>>>>>>> On Jun 2, 2009, at = 4:11 PM, wrote:=0A>>>>>>>>> =0A>>>>>>>>= >> =0A>>>>>>>>>> Hi all,=0A>>>>>>>>>> =0A>>>>>>>>>> Please see inline comme= nt.=0A>>>>>>>>>> =0A>>>>>>>>>> Regards,=0A>>>>>>>>>> Pierrick=0A>>>>>>>>>> = =0A>>>>>>>>>>> ________________________________________=0A>>>>>>>>>>> De : = mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De =0A>>>>>>>>>>> la p= art de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:35 =C0 :=0A>>>>>>>>= >>> Hesham Soliman; mext Objet : Re: [MEXT] Important =0A>>>>>>>>>>> consid= erations for directionality of flowbindings=0A>>>>>>>>>>> =0A>>>>>>>>>>> He= sham,=0A>>>>>>>>>>> This is nice story and makes some sense for the discssi= on, =0A>>>>>>>>>>> however some details are ommited. In your adventure with= the =0A>>>>>>>>>>> helpdesk, it (the=0A>>>>>>>>>>> helpdesk) is a third pa= rty service and thus your conclusions =0A>>>>>>>>>>> make sence.=0A>>>>>>>>= >>> Think of the situation when superior of a heldesk person =0A>>>>>>>>>>>= will tell him/her to check access point in some room. Would =0A>>>>>>>>>>>= it be the same reaction? I assume not. By that I mean that =0A>>>>>>>>>>> = if, for example, I'll install home agent in my home network, =0A>>>>>>>>>>>= I can make it know anything I want about MN, and more =0A>>>>>>>>>>> intre= sting is that how I will do it, does not require any standardization.=0A>>>= >>>>>>>> In other words, I'm superior of my HA.=0A>>>>>>>>>>> This situatio= n is not unthinkable, I personally believe that =0A>>>>>>>>>>> this is much= more efficient way of using HA fnctionality as =0A>>>>>>>>>>> opposed to b= ig service providers who will have to fight with =0A>>>>>>>>>>> scalability= and performance.=0A>>>>>>>>>>> However, one does not exclude another.=0A>>= >>>>>>>>> Difference between policies and rules is a convertion step.=0A>>>= >>>>>>>> =0A>>>>>>>>>>> =0A>>>>>>>>>> =0A>>>>>>>>>> =0A>>>>>>>>>> The diffe= rence between policy and rules is not only a matter =0A>>>>>>>>>> of conver= sion. A policy, is a static, or quasi-static, set of =0A>>>>>>>>>> guidance= for the MN (e.g use access network X for application =0A>>>>>>>>>> type=0A= >>>>>>>>>> A,...) while a rule update requires to be more dynamic. I mean:= =0A>>>>>>>>>> eventually a policy could be updated depending on network =0A= >>>>>>>>>> condition (e.g if X overloaded, use access network Y for =0A>>>>= >>>>>> application type A,...) but a rule reacts on local triggers (e.g.=0A= >>>>>>>>>> modification of the radio link=0A>>>>>>>>>> quality) with a shor= ter period of variation. So, IMHO, there =0A>>>>>>>>>> is no requirement fo= r updating policy on a short period and =0A>>>>>>>>>> out-of-band mechanism= can be used (e.g. IEEE 802.21 in push =0A>>>>>>>>>> mode,...).=0A>>>>>>>>>= =0A>>>>>>>>> Fully agree!=0A>>>>>>>>> This is why I do not support the exc= hange of rules from the HA =0A>>>>>>>>> to the MN.=0A>>>>>>>>> Policies may= be exchanged from the HA to the MN, but MIP is =0A>>>>>>>>> definitely not= the protocol to transport them.=0A>>>>>>>>> =0A>>>>>>>>> Nicolas=0A>>>>>>>= >> =0A>>>>>>>>>> =0A>>>>>>>>>> =0A>>>>>>>>>> My 2 cents...=0A>>>>>>>>>> =0A= >>>>>>>>>>> =0A>>>>>>>>>>> Is there any reason to restrict where such conve= rtion takes place?=0A>>>>>>>>>>> True=0A>>>>>>>>>>> that a HA does not know= what is going on in the access =0A>>>>>>>>>>> network, on the other hand H= A may know what is the network =0A>>>>>>>>>>> condition between HA and corr= espondent node. Either of this =0A>>>>>>>>>>> information is important, if = not equally important.=0A>>>>>>>>>>> It is not really difficult to let an M= N to reject rules sent =0A>>>>>>>>>>> by HA, which in my view would be quit= e natural. This implies =0A>>>>>>>>>>> that HA must follow the rules instal= led by MN until explicit =0A>>>>>>>>>>> acceptance has been received from M= N.=0A>>>>>>>>>>> Such procedure is very similar to an MN beahviour when =0A= >>>>>>>>>>> initiating new BU, where MN is not supposed to send any =0A>>>>= >>>>>>> traffic before BU confirmation.=0A>>>>>>>>>>> BTW, what is the nume= rical representation of "rough consensus"?=0A>>>>>>>>>>> I assume is when m= ajority is for, is it so?=0A>>>>>>>>>>> Yuri=0A>>>>>>>>>>> =0A>>>>>>>>>>> = =0A>>>>>>>>>>> -----Original Message-----=0A>>>>>>>>>>> From: mext-bounces@= ietf.org [mailto:mext-bounces@ietf.org] =0A>>>>>>>>>>> On Behalf Of Hesham = Soliman=0A>>>>>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM=0A>>>>>>>>>>> T= o: mext=0A>>>>>>>>>>> Subject: [MEXT] Important considerations for directio= nality =0A>>>>>>>>>>> of flow bindings=0A>>>>>>>>>>> =0A>>>>>>>>>>> Hi all,= =0A>>>>>>>>>>> =0A>>>>>>>>>>> I've always been a fan of the IETF's traditio= n of rough =0A>>>>>>>>>>> concensus (as opposed to voting). To me, this imp= lies that =0A>>>>>>>>>>> you need to get your point across and get other pe= ople to =0A>>>>>>>>>>> see that point of view.=0A>>>>>>>>>>> As opposed to = other organisations that require their members =0A>>>>>>>>>>> to vote and e= nd up with rigid political positions.=0A>>>>>>>>>>> =0A>>>>>>>>>>> The chai= rs asked us about the directionality question of the =0A>>>>>>>>>>> flows b= indings.=0A>>>>>>>>>>> On the charter question, I said that the charter doe= sn't =0A>>>>>>>>>>> need to mention how a solution should work, but rather = what =0A>>>>>>>>>>> problem needs to be solved.=0A>>>>>>>>>>> Hence, as far= as the charter is concerned, I'm fine with =0A>>>>>>>>>>> transferring rul= es "between" the MN and HA without =0A>>>>>>>>>>> mentioning directions.=0A= >>>>>>>>>>> =0A>>>>>>>>>>> Nevertheless, we still need to agree on identify= ing the =0A>>>>>>>>>>> requirement for the solution. And when it comes to t= his, I'm =0A>>>>>>>>>>> strongly against voting and I'll practice this by e= xplaining =0A>>>>>>>>>>> in this email why I think rules can not be transfe= rred from =0A>>>>>>>>>>> the HA to the MN and that the only direction that = makes =0A>>>>>>>>>>> sense in MIP is=0A>>>>>>>>>>> MN->HA. I'll deliberatel= y ignore arguments like "some people =0A>>>>>>>>>>> MN->want=0A>>>>>>>>>>> = this" or "an SDO wants this". They fall under the =0A>>>>>>>>>>> "meaningle= ss words"=0A>>>>>>>>>>> category and I'm incapable of discussing them becau= se they =0A>>>>>>>>>>> come with voting attitudes. They all need to be just= ified if =0A>>>>>>>>>>> the WG wants to have a technical _discussion_.=0A>>= >>>>>>>>> =0A>>>>>>>>>>> Here are my reasons:=0A>>>>>>>>>>> =0A>>>>>>>>>>> = 1. The HA does not know whether a CoA is tied to a certain =0A>>>>>>>>>>> a= ccess technology. It is one thing for the HA to send a =0A>>>>>>>>>>> messa= ge saying "forward port 80 traffic on a wifi link" (a=0A>>>>>>>>>>> policy)= and a completely different thing to say "forward =0A>>>>>>>>>>> port 80 tr= affic using CoA 3ffe::1"=0A>>>>>>>>>>> (a rule).=0A>>>>>>>>>>> =0A>>>>>>>>>= >> 2. You might argue that the HA can be told by the MN that=0A>>>>>>>>>>> = 3ffe::1 is tied to a wifi access, so what's the problem now?=0A>>>>>>>>>>> = The problem is that the HA has no idea about dynamic changes =0A>>>>>>>>>>>= on that wifi link. It doesn't know if it's congested, it =0A>>>>>>>>>>> do= esn't know what application is using port 80 (it doesn't =0A>>>>>>>>>>> hav= e to be web=0A>>>>>>>>>>> traffic) or port 8000 for that matter and doesn't= even know =0A>>>>>>>>>>> if the AP of that wifi link works at all.=0A>>>>>= >>>>>> Finally, it=0A>>>>>>>>>>> doesn't know the user's policies or other = admin policies for =0A>>>>>>>>>>> that MN.=0A>>>>>>>>>>> This type of infor= mation needs to be sent regularly because =0A>>>>>>>>>>> it changes all the= time and requires serious cross layer =0A>>>>>>>>>>> integration including= sometimes layer 8 integration! It's =0A>>>>>>>>>>> completely impractical.= =0A>>>>>>>>>>> =0A>>>>>>>>>>> 3. If the HA installed rules in the MN, what = happens if the =0A>>>>>>>>>>> MN wants to change those rules. Say the wifi = link went down, =0A>>>>>>>>>>> or the MN's wifi interface went down and it = wants to move =0A>>>>>>>>>>> that traffic to another interface. Would the H= A reject such move?=0A>>>>>>>>>>> Does the MN have to justify to the HA why= it needs to move =0A>>>>>>>>>>> traffic? Does that involve writing a lette= r perhaps?=0A>>>>>>>>>>> If you say "well in that case, the HA should let t= he MN move =0A>>>>>>>>>>> the traffic"=0A>>>>>>>>>>> then I'll ask you: wha= t's the point of having the HA install =0A>>>>>>>>>>> this stuff if it has = no authority and how does it know the =0A>>>>>>>>>>> reason for the MN's mo= vement of the flow?=0A>>>>>>>>>>> The way to control how users do things is= to incentivise =0A>>>>>>>>>>> them with charging models and show them that= things work =0A>>>>>>>>>>> better on certain technologies, not by installi= ng rules that =0A>>>>>>>>>>> can't be followed. It's a broken mindset and w= e've known =0A>>>>>>>>>>> that it's broken for a long time.=0A>>>>>>>>>>> = =0A>>>>>>>>>>> 4. Some people mentioned that the HA should be able to =0A>>= >>>>>>>>> revoke flows on the MN. I'm perfectly fine with that, just =0A>>>= >>>>>>>> extend the binding revocation draft to handle flows and the =0A>>>= >>>>>>>> rest is pretty straight forward.=0A>>>>>>>>>>> =0A>>>>>>>>>>> Fina= lly, I'll indulge in a true story that happened to me a =0A>>>>>>>>>>> few = years ago when I found that my wifi link wasn't working =0A>>>>>>>>>>> in a= hotel (no=0A>>>>>>>>>>> radio)=0A>>>>>>>>>>> and called the help desk. He = insisted that the link was up =0A>>>>>>>>>>> an I insisted that it wasn't. = When I asked him to tell me =0A>>>>>>>>>>> how he knows the link is up he s= aid: I can ping the AP! Of =0A>>>>>>>>>>> course after another=0A>>>>>>>>>>= > 5 minutes of trying to convince him that pinging the AP =0A>>>>>>>>>>> do= esn't mean the radio is actually working he sent someone =0A>>>>>>>>>>> to = the hotel who in turn realised that the radio was not working.=0A>>>>>>>>>>= > For those people who want rules to be transferred from the =0A>>>>>>>>>>>= HA to the MN, please think of your HA as this help desk person, i.e.=0A>>>= >>>>>>>> it has no clue about what's happening at the other end.=0A>>>>>>>>= >>> =0A>>>>>>>>>>> I hope this helps with the realisation that decisions ca= n't =0A>>>>>>>>>>> be made here based on voting and that there is little me= rit =0A>>>>>>>>>>> to transferring rules from the HA to the MN. Policies ca= n be =0A>>>>>>>>>>> transferred without any problems, but not rules.=0A>>>>= >>>>>>> =0A>>>>>>>>>>> Hesham=0A>>>>>>>>>>> =0A>>>>>>>>>>> =0A>>>>>>>>>>> = =0A>>>>>>>>>>> =0A>>>>>>>>>>> =0A>>>>>>>>>>> ______________________________= _________________=0A>>>>>>>>>>> MEXT mailing list=0A>>>>>>>>>>> MEXT@ietf.o= rg=0A>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext=0A>>>>>>>>>>> _= ______________________________________________=0A>>>>>>>>>>> MEXT mailing l= ist=0A>>>>>>>>>>> MEXT@ietf.org=0A>>>>>>>>>>> https://www.ietf.org/mailman/= listinfo/mext=0A>>>>>>>>>> _______________________________________________= =0A>>>>>>>>>> MEXT mailing list=0A>>>>>>>>>> MEXT@ietf.org=0A>>>>>>>>>> htt= ps://www.ietf.org/mailman/listinfo/mext=0A>>>>>>>>> =0A>>>>>>>> =0A>>>>>>>>= =0A>>>>>>> =0A>>>>>>> =0A>>>>>> =0A>>>>>> =0A>>>>> =0A>>>>> =0A>>>> =0A>>>= > =0A>>> =0A>>> =0A>> =0A>> =0A> =0A> =0A=0A=0A____________________________= ___________________=0AMEXT mailing list=0AMEXT@ietf.org=0Ahttps://www.ietf.= org/mailman/listinfo/mext=0A=0A=0A=0A From yuri.ismailov@ericsson.com Mon Jun 8 00:50:42 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AABFD3A6810 for ; Mon, 8 Jun 2009 00:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.049 X-Spam-Level: X-Spam-Status: No, score=-8.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 taFVeNGibSJ2 for ; Mon, 8 Jun 2009 00:50:39 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9B73B3A6910 for ; Mon, 8 Jun 2009 00:50:38 -0700 (PDT) X-AuditID: c1b4fb3e-b7b2dae00000205f-98-4a2cc2d12887 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id BF.E1.08287.1D2CC2A4; Mon, 8 Jun 2009 09:50:42 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jun 2009 09:50:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Jun 2009 09:50:40 +0200 Message-ID: In-Reply-To: <683217.323.qm@web111404.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: Acnl+oD6HjoRT5oRRHuLTG1yZBkeUACEr0VQ References: <683217.323.qm@web111404.mail.gq1.yahoo.com> From: "Yuri Ismailov" To: "Behcet Sarikaya" X-OriginalArrivalTime: 08 Jun 2009 07:50:41.0733 (UTC) FILETIME=[D24E3750:01C9E80D] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 07:50:42 -0000 Behcet, This is what I found in the charter. = (http://www.ietf.org/html.charters/mext-charter.html) ******************************************************************** - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. ********************************************************************* So the discussion how HA can influence choice of interfaces in MN is = under the charter cover or I missunderstood something? /yuri =20 -----Original Message----- From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Friday, June 05, 2009 6:27 PM To: Yuri Ismailov Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings Hi Yuri, =A0 I agree with all of your assumptions, I think they are all relevant = to flow mobility discussions. =A0 However in order to have some progress, I would like to know the = results of Marcelo's poll. I would like to see people stop questioning = the charter, esp. no HA to MN flow binding, etc.. =A0 Once that is done, I think the next thing is to discuss on a = specific draft which gives a solution to HA to MN flow binding. Regards, Behcet ----- Original Message ---- From: Yuri Ismailov To: Hesham Soliman ; Nicolas Montavont = ; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Sent: Friday, June 5, 2009 7:46:37 AM Subject: Re: [MEXT] Important considerations for directionality of = flowbindings Hesham, Let's proceed with sorting out what we are talking about, this probably = will help structuring examples and scenarious My assumptions: (probably shuold have been mentioned earlier) If we will = agree on assumptions, then it will make sense to go further on. First is that I assume that we have simulteneous multiaccess in mind, = i.e. MN has more than one interface to choose from for its flows. If = this is not the case then I will stop the discussion. This assumption is = based on the fact that we are (I hope at least) discussing flow = mobility. Secondly, I consider that MN chooses an interface but not CoA. I gave a = though about that and did not come up with any information which can be = derived from CoA in order to choose it. An interface has at least = expected characteristics, thus can be a subject of choice. Any = clarification about that would be appreciated. Next assumptions are about possible configurations of HA - Single HA for all interfaces configured in the mobile. HA can belong = to any of the access providers of each of access technology used by MN. - One HA per access or set of accesses, which is subset of all access = techologies presented or potentially may be presented (detached devices) = in MN. Anticipating numerous questions about that can say that I looked at such = configuration and did not find anything strange with it, i.e. (1) it = works, (2) it does not require any change to MIP or any other of its = extensions. (3) Configuration is performed per interface and does not = introduce any ambiguities. (4) it is natural for access provider to = offer HA service. - "Residential" HA. Assumption is that it can be either one of HA's or a = single HA for all types of accesses. This is the matter of MN = configuration. "Residential". - Any HA may have multiple interfaces, e.g. "residential" HA may be = connected to mobile broadband, DSL, etc. Next assumption comes from the example (e.g. latest one) - Traffic shaping is applied in both directions (up/down) link (in = practice this is the case). - Traffic shaping (TS) is applied to user subscription. In other words = TS is applied to packets belonging to a particular subscription but not = to an aggregated traffic on gateway interfaces. HA is not necessary = (however, nothing prevents from that) a gateway where TS is applied. I hope that I have not missed something, although it may be possible. If we can agree on that or correct if something is wrong here and agree = later then we know how to proceed further on /yuri -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com] Sent: Friday, June 05, 2009 11:37 AM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings Yuri, > Still not clear for me why you call scenarious invalid? > Some broadband providers (this is used in practice) have quota on the=20 > amount of traffic sent by users. Once quota is exceeded provider=20 > downgardes outgoing traffic from its network to 64Kbs (this figure is=20 > the real example from real provider). Such combination of to paths,=20 > where one is high speed, lets say 10 Mbs and another one is 64Kbs is = quite crusual to apps running on top of TCP. > Not for all types of traffic though. =3D> Yes I know the scenario but I keep saying to you that the change in = upstream routing in the HA has nothing to do with CoA selection by the = MN in the visited network. If anything, you want the MN to change it's = HoA depending on how the switch to another upstream ISP works. It's a = completely irrelevant issue to this discussion. Do you agree? If not why = not? I really want to see an answer to this point. >=20 > MN can not know about this situation. Nobody will send this = information to MN. =3D> Yes and if it knows what will it do??? If you can answer that you = will fix the deadlock we have. > That means that MN will choose its interfaces based on its knowledge=20 > about 10Mbs link capabilities. =3D> You're talking about two different things. The MN doesn't choose = the HA's outgoing interface! What am I missing? Obtaining this isnformation from HA is quite > significant to make a better decision about choice of interfaces for =20 >its flows. >=A0 This is concrete example of what happens in the reality. > Do you consider that this information will be useless for MN? =3D> Completely useless. Unless I'm missing something in your scenario. = Just write down step by step what will happen and include messages. I = don't see how this can possibly be relevant to the MN. Hesham Hesham >=20 > /yuri >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Thursday, June 04, 2009 4:38 PM > To: Yuri Ismailov; Nicolas Montavont;=20 > pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of=20 > flowbindings >=20 > Yuri, >=20 >=20 > On 5/06/09 12:01 AM, "Yuri Ismailov" = wrote: >=20 >> Hesham, >>=20 >> I provided several scenarious which you said are invalid. This is=20 >> where my conclusion about standpoint comes from. >> Whether you call hints policies or rules it does not change what=20 >> information can be provided by HA to MN. >=20 > =3D> It changes the outcome for the work item we're discussing. I'm=20 > trying to come to a conclusion on this and there is a huge difference=20 > between transferring policies and installing flow bindings. >=20 >> By sending rules HA does not install anything in MN. Likewise, MN=20 >> does not install rules in HA, it informs HA about currently made = choices. >> As I remember rules will not be valid until proper Ack arrival, which = >> for me means that may not be instantiated at all. >> Niether rules nor polices are specific to MIP. As I wrote those can=20 >> be exchanged between hosts without any MIP implementation, just for=20 >> access selection purposes. Once it was decided to make it as part of=20 >> MIP protocol, I'm fine with that. Do not have any idea to discuss=20 >> this, while personally consider that the work on rules transfer can=20 >> very well fit into the MEXT group but as a separate work item, but=20 >> this is not the case now, so good enough the way it is. >> And back again, it really gets repeated, so will lead to nowhere,=20 >> you've got my arguments and tell that the information, which I'm=20 >> talking about, is not usefull. What can I say more? I can put you on=20 >> my position and start asking questions instead of answering. So, why=20 >> it is not usefull? >=20 > =3D> I explained why the specific information you mentioned was not=20 > useful/useable by the MN and this is what I referred to as unanswered. > Because if you agree with my previous explanations then we don't need=20 > to discuss it further. If you disagree you certainly didn't tell me=20 > why. You have the charge of proof because you want to change the way=20 > MIP works currently, that's all I'm trying to say. >=20 > Hesham >=20 >>=20 >> /yuri >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Thursday, June 04, 2009 4:00 AM >> To: Yuri Ismailov; Nicolas Montavont;=20 >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of=20 >> flowbindings >>=20 >> Yuri, >>=20 >>=20 >>=20 >>> Missing is additional information which may be helpful in making=20 >>> better decision about interface selection by MN. >>> Which information is that I wrote in my previous emails. Back to my=20 >>> examples (not all, do not want to repeat myself). If HA will have=20 >>> changed traffic shaping parameters on one of the incoming or=20 >>> outgoing interfaces, this will be important information for MN to = know. >>> We have agreed already that whether this information important or=20 >>> not, benfitial or not is a matter of standpoint. >>=20 >> =3D> I don't agree or like to think that it's a matter of standpoint. >> That's why I asked you on every point you raised and compared this to = >> the MN's knowledge on e2e basis. Once we have "standpoints" then=20 >> we're getting outside the technical realm. The reason I don't think=20 >> it's useful is that this information cannot be used by the MN to=20 >> select a CoA. I've already stated that before and you seemed to agree = >> so I don't know why you repeat this as a reason for the HA to install = >> filters in the MN. Let me say it >> again: There is no correlation between the routing on the HA's=20 >> upstream interfaces/ISP with the MN's selection of a CoA. >>=20 >>> I consider that knowing more is a benefit and will help to get=20 >>> better result. >>>=20 >>> My point is still the same. I see the reverse rules sending as=20 >>> possibility to provide more information to the MN, thus make MN to=20 >>> get to better decision about interface selection for its flows. This = >>> point has not changed since the beginning of the discussion. >>=20 >> =3D> This is why we're not making progress IMO: >>=20 >> 1. The hints you refer to are not the same things as installing rules = >> on the MN. Completely different information in fact. You've=20 >> essentially proved that when you suggested that the MN can accept or=20 >> reject them. So, let's not call them rules. The more direct word for=20 >> what you want to send is policies >>=20 >> 2. You didn't provide a valid scenario that we can discuss as to why=20 >> it's needed or how it could work. I've asked numerous questions in=20 >> each email that were not answered (with the exception of the last=20 >> email). It's not possible to progress the discussion without=20 >> answering each others' >> questions. You can go back through the threads and verify this. >>=20 >> 3. If we're sending rules from the HA to the MN and the MN can reject = >> those rules then the whole exercise is pointless. You really want to=20 >> send policies not rules. I can imagine those policies being one of=20 >> the inputs that the MN uses to make a decision. I still fail to see=20 >> how anything happening on the HA's upstream interfaces/ISP link can=20 >> possibly influence the MN's decision for CoA selection. This is=20 >> another unanswered question. >>=20 >> Hesham >>=20 >>>=20 >>> /yuri >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Wednesday, June 03, 2009 4:09 PM >>> To: Yuri Ismailov; Nicolas Montavont;=20 >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>> flowbindings >>>=20 >>>=20 >>>=20 >>>=20 >>> On 3/06/09 10:47 PM, "Yuri Ismailov" = wrote: >>>=20 >>>> Ok, see your point, however:-) >>>>=20 >>>> The major difference here is that your are talking about CoA=20 >>>> selection and I'm talking about interface selection. Quite a big=20 >>>> difference. >>>=20 >>> =3D> No, that's not the point really. The point is that there is no=20 >>> relationship between CoA/interface selection on the MN and the=20 >>> upstream ISP for the home network. >>>=20 >>>> I do not see any grounds for MN to select CoA, based on what?=20 >>>> Prefix length? >>>> While selection of an interface is based on expected=20 >>>> characteristics of the communication. Routes (up/down)link in my=20 >>>> opinion do have impact on the characteristics and this is exactly=20 >>>> the information missing in the MN when selecting interface. >>>=20 >>> =3D> There is nothing missing for the MN to make this selection.=20 >>> Please tell us specifically what is missing. You're changing points=20 >>> on me all the time now. >>> Lets stick to one point at a time. What's missing? >>>=20 >>>>=20 >>>> Whenever, MN decides to move a flow, the reason can be anything but = >>>> not which CoA it has configured on each interface. >>>>=20 >>>> Another thing is that MN will notice something e2e if and only if=20 >>>> such support is implemented in the MN. >>>=20 >>> =3D> Of course, so what? >>>=20 >>>=A0 Moreover, this notice can not be made at IP layer.. >>>> TCP fights alone with all problems and never tells to any other=20 >>>> layer what is going on. So what is left? Two options. Add this=20 >>>> support to operating system, which makes its (support) existence=20 >>>> questionable, or to applications, which is even more questionable. >>>=20 >>> =3D> It's interesting that you think it's questionable to add the=20 >>> support to the MN's OS but not questionable to add the support to=20 >>> the HA's OS, which will not lead to the same reliability as if it=20 >>> were done in the MN. It doesn't make sense to me. >>>=20 >>>>=20 >>>>>>=20 >>>>>> Well, that's debatable, but this is clearly not a reason to do = anything. >>>>>>=20 >>>> Are you serious about that MIP may be broken because of that? >>>=20 >>> =3D> Yes! It's not designed to do what you want to do. Luckily, in=20 >>> this case what you want, IMO, is broken anyway so it's not a = problem. >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> /yuri >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Wednesday, June 03, 2009 1:15 PM >>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>>> flowbindings >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Still some answers, despite knowing that in your opinion they are=20 >>>>> not benefits. >>>>>=20 >>>>> First of all MIP will not be breaked if the rules will be sent in=20 >>>>> both directions.. >>>>=20 >>>> =3D> Well, that's debatable, but this is clearly not a reason to do = anything. >>>>=20 >>>>>=20 >>>>> - Access provider preferences relate to the use of backbone=20 >>>>> provider, which may vary with the time of day. Changing backbone=20 >>>>> provider can make quite big difference for commnication between HA = >>>>> (if HA service is provided by the same access provider) and CN(s). >>>>> The difference can be expressed in, let's say, number of hops,=20 >>>>> load, possibly something else. Such change is an event and may=20 >>>>> have an impact on the overall communication. This can be told=20 >>>>> directly to MN or HA. Direct communication to MN (if accepted as >>>>> benefit:-)) in such case will need standardization. Communication=20 >>>>> of this information to HA does not (I consider this as a benefit). >>>>> HA may act upon that event, and the rest you >>>>> know: rules in reverse direction. >>>>=20 >>>> =3D> There is no need to _tell_ the MN anything. There are two = issues here. >>>> First, changing network conditions are best known e2e. So the MN=20 >>>> will know that anyway based on the traffic running between it and = the CN. >>>> The other issue is related to cost for certain times of day. This=20 >>>> is a routing issue in the HA and has nothing to do with which=20 >>>> interface the MN selects. The selected CoA has zero impact on the=20 >>>> HA's upstream selection. Completely irrelevant actually. >>>> Of course, as far as cost on the visited link, the MN knows best. >>>>=20 >>>>>=20 >>>>> - Access provider may set up different parameters for traffic=20 >>>>> shaping for each of HA interfaces. These preferences may vary=20 >>>>> independently of change of backbone provider but dependently on=20 >>>>> the time of day. >>>>> The rest you know, whether it changes somebodies opinion. >>>>=20 >>>> =3D> But again, this has zero effect on CoA selection. The two = issues=20 >>>> are completely orthogonal. Selecting CoA1 or CoA2 has zero impact=20 >>>> on the HA's upstream route. >>>>=20 >>>>>=20 >>>>> - I presume that in RO mode this is similar to HA mode, and I'm in = >>>>> when it comes to send rules in reverse direction between CN and = MN. >>>>> Benefits of doing that is that any change percieved by CN as=20 >>>>> important to react upon can be expressed in proposal of new rules. >>>>> The sources causing changes may include but not limited to, are=20 >>>>> user, network managemnt events, application generated events, etc. >>>>>=20 >>>>> So feel free to consider this as benefits or not >>>>=20 >>>> =3D> You seem to think that there is a relationship between = upstream=20 >>>> routing and CoA selection. That's not the case at all. These are=20 >>>> two different addresses from two different networks. >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> /yuri >>>>>=20 >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: Wednesday, June 03, 2009 11:47 AM >>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>> pierrick.seite@orange-ftgroup.com >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of = >>>>> flowbindings >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 3/06/09 7:33 PM, "Yuri Ismailov" = wrote: >>>>>=20 >>>>>> Hesham, >>>>>>=20 >>>>>> Whenever we talk about sending additional information, the "waste = >>>>>> of bandwidth" can be brought up. So I do not have an answer for=20 >>>>>> that besides speculations around it. >>>>>=20 >>>>> =3D> no no, I don't mean it literally, I mean that the message=20 >>>>> doesn't do anything, i.e. Has no benefit. >>>>>=20 >>>>>>=20 >>>>>> Speaking about benefits, everybody who knows the area is capable=20 >>>>>> of turning things up side down. I assume it is subjective=20 >>>>>> standpoint of considering things as benefits or disadvantages and = >>>>>> all is about to agree or disagree. >>>>>=20 >>>>> =3D> That's fine, I'm asking for benefits in your opinion not=20 >>>>> someone else's. >>>>> It's impossible to discuss this if I can't see any benefits=20 >>>>> because you didn't send any. What you sent were actions that can=20 >>>>> be done by the HA and I responded by saying that the same (or >>>>> more) information is available to the MN. Therefore, if you think=20 >>>>> there are additional benefits to doing this in the HA then you = need to tell us. >>>>>=20 >>>>> The bottom line is this: MIP works by letting the MN install=20 >>>>> bindings in the HA. If you want things to work in reverse you need = >>>>> to justify it. I can't see any justifications because you're not=20 >>>>> answering my questions on your scenarios. So, count me out on the=20 >>>>> reverse direction :). >>>>>=20 >>>>>=20 >>>>> For >>>>>> me those I wrote about are benefits or potential benefits if you = want. >>>>>=20 >>>>> =3D> No you didn't.. You wrote about things that can be done. Many = >>>>> things can be done by many entities, the question is why the HA=20 >>>>> and not the MN. >>>>>=20 >>>>>> One important thing in the discussion, although mentioned, but=20 >>>>>> forgotten later is that by making rules distribution one way=20 >>>>>> only, we do create limitation for benefits, or potential benefits = >>>>>> if this sounds better. >>>>>=20 >>>>> =3D> Well, we won't know what we're missing unless someone tells = us. >>>>> So far no one has mentioned the advantages of doing things in the=20 >>>>> reverse direction. >>>>> There is always something missing from a protocol (it's=20 >>>>> engineering), the question us whether it's significant or worth=20 >>>>> the trouble. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>>=20 >>>>>> /yuri >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>> Sent: Wednesday, June 03, 2009 10:10 AM >>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>> pierrick.seite@orange-ftgroup.com >>>>>> Cc: mext@ietf.org >>>>>> Subject: Re: [MEXT] Important considerations for directionality=20 >>>>>> of flowbindings >>>>>>=20 >>>>>> Yuri, >>>>>>=20 >>>>>> I can't parse those events you refer to. I'l answer both emails = here. >>>>>> First the events you refer to: >>>>>>=20 >>>>>>>> - network condition towards CN(s) >>>>>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>>>>=20 >>>>>> =3D> What's the event? A change in those conditions? The MN knows = >>>>>> the conditions of the e2e path as well as or better than the HA. >>>>>> What is the benefit of having the HA send a hint and how reliable = >>>>>> is that hint anyway? >>>>>>=20 >>>>>>>> - Access provider (any access, not necessarily wireless) who=20 >>>>>>>> offeres HA services preferences change >>>>>>=20 >>>>>> =3D> Preferences change to what?? How does it know if such change = >>>>>> works for the MN at all? This is way too vague to be able to=20 >>>>>> discuss tradeoffs. >>>>>>=20 >>>>>>>> - Change of the access provider traffic to another backbone=20 >>>>>>>> provider due to the time of the day. >>>>>>>> - Traffic condition on HA interface, which accepts traffic from = >>>>>>>> MN if MN sends on some particular local interface >>>>>>=20 >>>>>> =3D> These are path changes. The HA has _no idea_ how such a = change=20 >>>>>> affects each MN/CN combination and it's "hint" can cause more=20 >>>>>> problems than it solves. BTW, if you're talking about hints then=20 >>>>>> we're no longer talking about installing bindings in the MN. This = >>>>>> is a different topic. MIP doesn't transfer hints, it pretty much=20 >>>>>> sends "orders" >>>>>> from one end to another. >>>>>>=20 >>>>>> Now to the actions required by the MN: >>>>>>=20 >>>>>>> - reject, >>>>>>> - re-evaluate and reject >>>>>>> - re-evaluate and accept >>>>>>> - accept >>>>>>=20 >>>>>> =3D> First, by assuming that the MN can reject the "hint" as you=20 >>>>>> call it you invalidate the whole argument for the HA to install = rules. >>>>>> Rejecting a hint or even evaluating it means that the MN knows = more. >>>>>> Therefore, the HA's hint is a complete waste of bandwidth. >>>>>>=20 >>>>>> I'm still confused about the _benefits_ you see here. Or are you=20 >>>>>> assuming that the MN can't know those hints without the HA's=20 >>>>>> involvement? But if you're assuming that, then how can it reject=20 >>>>>> the hints? This whole proposal makes no sense to me at all. Not=20 >>>>>> to mention the complexity you implicitly assume in order to=20 >>>>>> generate those, hopefully reliable, hints. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>=20 >>>>>> On 3/06/09 5:23 PM, "Yuri Ismailov" = wrote: >>>>>>=20 >>>>>>> Hesham, >>>>>>>=20 >>>>>>> In my view these are events not scenarious. These events are=20 >>>>>>> known by HA but not MN. If HA acts upon events, given that it=20 >>>>>>> knows somewhat more about MN, not only IP addresses, it (HA) can = >>>>>>> generate new rules and send them as hint to MN. Back again, MN=20 >>>>>>> has four >>>>>>> options: >>>>>>>=20 >>>>>>> The benefit will be obviously that the new rules (if accepted)=20 >>>>>>> may llead to a better overall communication characteristics. >>>>>>>=20 >>>>>>> /yuri >>>>>>>=20 >>>>>>>=20 >>>>>>> =3D> I'm trying to understand what you mean above. These are all = >>>>>>> scenarios, the question is: What is the benefit for the HA to=20 >>>>>>> transfer rules? The HA will not know the path between the MN and = >>>>>>> CN more than either node does. So I don't understand what=20 >>>>>>> _benefits_ you see here. >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Pretty much sure that there are more examples and I encourage=20 >>>>>>>> to think about those not from MN point of view but rather from=20 >>>>>>>> the HA service provider. >>>>>>>>=20 >>>>>>>> /yuri >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>> Cc: mext@ietf.org >>>>>>>> Subject: Re: [MEXT] Important considerations for directionality = >>>>>>>> of flowbindings >>>>>>>>=20 >>>>>>>> Yuri, >>>>>>>>=20 >>>>>>>>=A0 It is just rules TRANSFER which is the matter of MIP. So = where >>>>>>>>> is the logic when saying that MN to HA rules transfer is a=20 >>>>>>>>> practical engineering and HA to MN is an academic interest? >>>>>>>>=20 >>>>>>>> =3D> I think we've (I'm including myself) highlighted several=20 >>>>>>>> reasons for why it makes little sense to transfer rules from HA = to MN. >>>>>>>> Instead of rat-holing on theory Vs practice, you (or others=20 >>>>>>>> advocating the other direction) need to come up with reasons=20 >>>>>>>> for doing things this way. This way we can think like engineers = >>>>>>>> about tradeoffs. >>>>>>>> Absent that, I don't see any point in having theory Vs practice = >>>>>>>> high level discussions, which will lead nowhere. >>>>>>>>=20 >>>>>>>> Hesham >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards >>>>>>>>> Yuri >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>> directionality of flowbindings >>>>>>>>>=20 >>>>>>>>> Hi Pierrick, >>>>>>>>>=20 >>>>>>>>> On Jun 2, 2009, at 4:11 PM, = wrote: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Hi all, >>>>>>>>>>=20 >>>>>>>>>> Please see inline comment. >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>> Pierrick >>>>>>>>>>=20 >>>>>>>>>>> ________________________________________ >>>>>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De = >>>>>>>>>>> la part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 = 09:35 =C0 : >>>>>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important=20 >>>>>>>>>>> considerations for directionality of flowbindings >>>>>>>>>>>=20 >>>>>>>>>>> Hesham, >>>>>>>>>>> This is nice story and makes some sense for the discssion,=20 >>>>>>>>>>> however some details are ommited. In your adventure with the = >>>>>>>>>>> helpdesk, it (the >>>>>>>>>>> helpdesk) is a third party service and thus your conclusions = >>>>>>>>>>> make sence. >>>>>>>>>>> Think of the situation when superior of a heldesk person=20 >>>>>>>>>>> will tell him/her to check access point in some room. Would=20 >>>>>>>>>>> it be the same reaction? I assume not. By that I mean that=20 >>>>>>>>>>> if, for example, I'll install home agent in my home network, = >>>>>>>>>>> I can make it know anything I want about MN, and more=20 >>>>>>>>>>> intresting is that how I will do it, does not require any = standardization. >>>>>>>>>>> In other words, I'm superior of my HA. >>>>>>>>>>> This situation is not unthinkable, I personally believe that = >>>>>>>>>>> this is much more efficient way of using HA fnctionality as=20 >>>>>>>>>>> opposed to big service providers who will have to fight with = >>>>>>>>>>> scalability and performance. >>>>>>>>>>> However, one does not exclude another. >>>>>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> The difference between policy and rules is not only a matter=20 >>>>>>>>>> of conversion. A policy, is a static, or quasi-static, set of = >>>>>>>>>> guidance for the MN (e.g use access network X for application = >>>>>>>>>> type >>>>>>>>>> A,...) while a rule update requires to be more dynamic. I = mean: >>>>>>>>>> eventually a policy could be updated depending on network=20 >>>>>>>>>> condition (e.g if X overloaded, use access network Y for=20 >>>>>>>>>> application type A,...) but a rule reacts on local triggers = (e.g. >>>>>>>>>> modification of the radio link >>>>>>>>>> quality) with a shorter period of variation. So, IMHO, there=20 >>>>>>>>>> is no requirement for updating policy on a short period and=20 >>>>>>>>>> out-of-band mechanism can be used (e.g. IEEE 802.21 in push=20 >>>>>>>>>> mode,...). >>>>>>>>>=20 >>>>>>>>> Fully agree! >>>>>>>>> This is why I do not support the exchange of rules from the HA = >>>>>>>>> to the MN. >>>>>>>>> Policies may be exchanged from the HA to the MN, but MIP is=20 >>>>>>>>> definitely not the protocol to transport them. >>>>>>>>>=20 >>>>>>>>> Nicolas >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> My 2 cents... >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Is there any reason to restrict where such convertion takes = place? >>>>>>>>>>> True >>>>>>>>>>> that a HA does not know what is going on in the access=20 >>>>>>>>>>> network, on the other hand HA may know what is the network=20 >>>>>>>>>>> condition between HA and correspondent node. Either of this=20 >>>>>>>>>>> information is important, if not equally important. >>>>>>>>>>> It is not really difficult to let an MN to reject rules sent = >>>>>>>>>>> by HA, which in my view would be quite natural. This implies = >>>>>>>>>>> that HA must follow the rules installed by MN until explicit = >>>>>>>>>>> acceptance has been received from MN. >>>>>>>>>>> Such procedure is very similar to an MN beahviour when=20 >>>>>>>>>>> initiating new BU, where MN is not supposed to send any=20 >>>>>>>>>>> traffic before BU confirmation. >>>>>>>>>>> BTW, what is the numerical representation of "rough = consensus"? >>>>>>>>>>> I assume is when majority is for, is it so? >>>>>>>>>>> Yuri >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Hesham Soliman >>>>>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>>>>> To: mext >>>>>>>>>>> Subject: [MEXT] Important considerations for directionality=20 >>>>>>>>>>> of flow bindings >>>>>>>>>>>=20 >>>>>>>>>>> Hi all, >>>>>>>>>>>=20 >>>>>>>>>>> I've always been a fan of the IETF's tradition of rough=20 >>>>>>>>>>> concensus (as opposed to voting). To me, this implies that=20 >>>>>>>>>>> you need to get your point across and get other people to=20 >>>>>>>>>>> see that point of view. >>>>>>>>>>> As opposed to other organisations that require their members = >>>>>>>>>>> to vote and end up with rigid political positions. >>>>>>>>>>>=20 >>>>>>>>>>> The chairs asked us about the directionality question of the = >>>>>>>>>>> flows bindings. >>>>>>>>>>> On the charter question, I said that the charter doesn't=20 >>>>>>>>>>> need to mention how a solution should work, but rather what=20 >>>>>>>>>>> problem needs to be solved. >>>>>>>>>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>>>>>>>>> transferring rules "between" the MN and HA without=20 >>>>>>>>>>> mentioning directions. >>>>>>>>>>>=20 >>>>>>>>>>> Nevertheless, we still need to agree on identifying the=20 >>>>>>>>>>> requirement for the solution. And when it comes to this, I'm = >>>>>>>>>>> strongly against voting and I'll practice this by explaining = >>>>>>>>>>> in this email why I think rules can not be transferred from=20 >>>>>>>>>>> the HA to the MN and that the only direction that makes=20 >>>>>>>>>>> sense in MIP is >>>>>>>>>>> MN->HA. I'll deliberately ignore arguments like "some people = >>>>>>>>>>> MN->want >>>>>>>>>>> this" or "an SDO wants this". They fall under the=20 >>>>>>>>>>> "meaningless words" >>>>>>>>>>> category and I'm incapable of discussing them because they=20 >>>>>>>>>>> come with voting attitudes. They all need to be justified if = >>>>>>>>>>> the WG wants to have a technical _discussion_. >>>>>>>>>>>=20 >>>>>>>>>>> Here are my reasons: >>>>>>>>>>>=20 >>>>>>>>>>> 1. The HA does not know whether a CoA is tied to a certain=20 >>>>>>>>>>> access technology. It is one thing for the HA to send a=20 >>>>>>>>>>> message saying "forward port 80 traffic on a wifi link" (a >>>>>>>>>>> policy) and a completely different thing to say "forward=20 >>>>>>>>>>> port 80 traffic using CoA 3ffe::1" >>>>>>>>>>> (a rule). >>>>>>>>>>>=20 >>>>>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem now? >>>>>>>>>>> The problem is that the HA has no idea about dynamic changes = >>>>>>>>>>> on that wifi link. It doesn't know if it's congested, it=20 >>>>>>>>>>> doesn't know what application is using port 80 (it doesn't=20 >>>>>>>>>>> have to be web >>>>>>>>>>> traffic) or port 8000 for that matter and doesn't even know=20 >>>>>>>>>>> if the AP of that wifi link works at all. >>>>>>>>>>> Finally, it >>>>>>>>>>> doesn't know the user's policies or other admin policies for = >>>>>>>>>>> that MN. >>>>>>>>>>> This type of information needs to be sent regularly because=20 >>>>>>>>>>> it changes all the time and requires serious cross layer=20 >>>>>>>>>>> integration including sometimes layer 8 integration! It's=20 >>>>>>>>>>> completely impractical. >>>>>>>>>>>=20 >>>>>>>>>>> 3. If the HA installed rules in the MN, what happens if the=20 >>>>>>>>>>> MN wants to change those rules. Say the wifi link went down, = >>>>>>>>>>> or the MN's wifi interface went down and it wants to move=20 >>>>>>>>>>> that traffic to another interface. Would the HA reject such = move? >>>>>>>>>>> Does the MN have to justify to the HA why it needs to move=20 >>>>>>>>>>> traffic? Does that involve writing a letter perhaps? >>>>>>>>>>> If you say "well in that case, the HA should let the MN move = >>>>>>>>>>> the traffic" >>>>>>>>>>> then I'll ask you: what's the point of having the HA install = >>>>>>>>>>> this stuff if it has no authority and how does it know the=20 >>>>>>>>>>> reason for the MN's movement of the flow? >>>>>>>>>>> The way to control how users do things is to incentivise=20 >>>>>>>>>>> them with charging models and show them that things work=20 >>>>>>>>>>> better on certain technologies, not by installing rules that = >>>>>>>>>>> can't be followed. It's a broken mindset and we've known=20 >>>>>>>>>>> that it's broken for a long time. >>>>>>>>>>>=20 >>>>>>>>>>> 4. Some people mentioned that the HA should be able to=20 >>>>>>>>>>> revoke flows on the MN. I'm perfectly fine with that, just=20 >>>>>>>>>>> extend the binding revocation draft to handle flows and the=20 >>>>>>>>>>> rest is pretty straight forward. >>>>>>>>>>>=20 >>>>>>>>>>> Finally, I'll indulge in a true story that happened to me a=20 >>>>>>>>>>> few years ago when I found that my wifi link wasn't working=20 >>>>>>>>>>> in a hotel (no >>>>>>>>>>> radio) >>>>>>>>>>> and called the help desk. He insisted that the link was up=20 >>>>>>>>>>> an I insisted that it wasn't. When I asked him to tell me=20 >>>>>>>>>>> how he knows the link is up he said: I can ping the AP! Of=20 >>>>>>>>>>> course after another >>>>>>>>>>> 5 minutes of trying to convince him that pinging the AP=20 >>>>>>>>>>> doesn't mean the radio is actually working he sent someone=20 >>>>>>>>>>> to the hotel who in turn realised that the radio was not = working. >>>>>>>>>>> For those people who want rules to be transferred from the=20 >>>>>>>>>>> HA to the MN, please think of your HA as this help desk = person, i.e. >>>>>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>>>>=20 >>>>>>>>>>> I hope this helps with the realisation that decisions can't=20 >>>>>>>>>>> be made here based on voting and that there is little merit=20 >>>>>>>>>>> to transferring rules from the HA to the MN. Policies can be = >>>>>>>>>>> transferred without any problems, but not rules. >>>>>>>>>>>=20 >>>>>>>>>>> Hesham >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> MEXT mailing list >>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> MEXT mailing list >>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>> _______________________________________________ >>>>>>>>>> MEXT mailing list >>>>>>>>>> MEXT@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext =20 From yuri.ismailov@ericsson.com Mon Jun 8 01:29:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE173A6B2A for ; Mon, 8 Jun 2009 01:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.062 X-Spam-Level: X-Spam-Status: No, score=-8.062 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 JVVGDMXE9Soy for ; Mon, 8 Jun 2009 01:29:26 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 19D453A695E for ; Mon, 8 Jun 2009 01:29:24 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9cae00000140d-a1-4a2ccbe80462 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 61.8A.05133.8EBCC2A4; Mon, 8 Jun 2009 10:29:28 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jun 2009 10:29:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Jun 2009 10:29:20 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkA== References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 08 Jun 2009 08:29:21.0548 (UTC) FILETIME=[3905E4C0:01C9E813] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 08:29:29 -0000 Hesham, It looks like that the only point of disagreement is about = changing HA and mapping between HA and access. Some explanations of what I mean below: 1. Changing HA. As it follows from group charter change of HA is in the plans of MEXT = WG. I assume that this is going to be a separate work item because the = reason specified for that is very specific and relates to deployment = more than to flow mobility. Do not want to speculate, about this right = now but the change of HA does not necessarily means change of rules. So the proposal is to not to discuss change of HA as you suggested. 2. In my example I do not mean change of HA as an explicit procedure = specified separately. One confirmation to that is that single HA for all = interfaces is included and valid option. Based on the HA -> MN exchange, = the MN may perform interface selection procedure and may choose another = interface for some flow(s). In multiple HA case it will result of the = rules update MN -> HA to the HA which is relevant for the new interface = chosen for flows. Please notice, There is nothing about HA change, only = about interface selection. 3. I do not map HA and access. It is allowed for any access provider to = offer HA service and once this is the case it will be so. Thus an MN can = have multiple HA configured for the use on different interfaces. Regards Yuri -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Friday, June 05, 2009 4:18 PM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings > First is that I assume that we have simulteneous multiaccess in mind,=20 > i.e. MN has more than one interface to choose from for its flows. If=20 > this is not the case then I will stop the discussion. This assumption=20 > is based on the fact that we are (I hope at least) discussing flow = mobility. =3D> Sure. >=20 > Secondly, I consider that MN chooses an interface but not CoA. I gave=20 > a though about that and did not come up with any information which can = > be derived from CoA in order to choose it. An interface has at least=20 > expected characteristics, thus can be a subject of choice. Any=20 > clarification about that would be appreciated. =3D> An application would choose an interface, but of course the IP = stack selects the corresponding address. I'm sure there is no = disagreement there. >=20 > Next assumptions are about possible configurations of HA > - Single HA for all interfaces configured in the mobile. HA can belong = > to any of the access providers of each of access technology used by = MN. =3D> Ok. >=20 > - One HA per access or set of accesses, which is subset of all access=20 > techologies presented or potentially may be presented (detached=20 > devices) in MN. =3D> Now you're getting into a different problem space from flow = mobility. This is why I wanted you to break the scenario down. We are not dealing = with multiple HoAs in this work item, we're dealing with multiple CoAs, = i.e. One HoA. > Anticipating numerous questions about that can say that I looked at=20 > such configuration and did not find anything strange with it, i.e. (1) = > it works, > (2) it does not require any change to MIP or any other of its=20 > extensions. (3) Configuration is performed per interface and does not=20 > introduce any ambiguities. (4) it is natural for access provider to = offer HA service. =3D> Yes of course it works but as I read this I'm guessing that you = want the MN to change HoA. This is not the problem we're discussing in = this WG. Another issue, I'm not comfortable with the wording of "HA per access" because they're not tied to access. Let's just say there are multiple = Has and not associate it with an access. >=20 > - "Residential" HA. Assumption is that it can be either one of HA's or = > a single HA for all types of accesses. This is the matter of MN = configuration. > "Residential". =3D> Please don't tie HA to access. >=20 > - Any HA may have multiple interfaces, e.g. "residential" HA may be=20 > connected to mobile broadband, DSL, etc. =3D> sure >=20 > Next assumption comes from the example (e.g. latest one) > - Traffic shaping is applied in both directions (up/down) link (in=20 > practice this is the case). > - Traffic shaping (TS) is applied to user subscription. In other words = > TS is applied to packets belonging to a particular subscription but=20 > not to an aggregated traffic on gateway interfaces. HA is not=20 > necessary (however, nothing prevents from that) a gateway where TS is = applied. >=20 >=20 > I hope that I have not missed something, although it may be possible. > If we can agree on that or correct if something is wrong here and=20 > agree later then we know how to proceed further on =3D> Your scenario is fine (with the wording changes for tying Has to = access). But I want to pre-empt any suggestion that the HA will tell the MN to = use a different HoA. This is very possible but it's not the problem = being discussed here. It may well be something for charter discussion = but it has zero impact on flow bindings for multiple CoAs. Hesham >=20 > /yuri >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Friday, June 05, 2009 11:37 AM > To: Yuri Ismailov; Nicolas Montavont;=20 > pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of=20 > flowbindings >=20 > Yuri, >=20 >=20 >> Still not clear for me why you call scenarious invalid? >> Some broadband providers (this is used in practice) have quota on the = >> amount of traffic sent by users. Once quota is exceeded provider=20 >> downgardes outgoing traffic from its network to 64Kbs (this figure is = >> the real example from real provider). Such combination of to paths,=20 >> where one is high speed, lets say 10 Mbs and another one is 64Kbs is=20 >> quite crusual to apps running on top of TCP. >> Not for all types of traffic though. >=20 > =3D> Yes I know the scenario but I keep saying to you that the change = in=20 > upstream routing in the HA has nothing to do with CoA selection by the = > MN in the visited network. If anything, you want the MN to change it's = > HoA depending on how the switch to another upstream ISP works. It's a=20 > completely irrelevant issue to this discussion. Do you agree? If not=20 > why not? I really want to see an answer to this point. >=20 > =20 >=20 >=20 >>=20 >> MN can not know about this situation. Nobody will send this=20 >> information to MN. >=20 > =3D> Yes and if it knows what will it do??? If you can answer that you = > will fix the deadlock we have. >=20 >> That means that MN will choose its interfaces based on its knowledge=20 >> about 10Mbs link capabilities. >=20 > =3D> You're talking about two different things. The MN doesn't choose=20 > the HA's outgoing interface! What am I missing? >=20 > Obtaining this isnformation from HA is quite >> significant to make a better decision about choice of interfaces for=20 >> its flows. >> This is concrete example of what happens in the reality. >> Do you consider that this information will be useless for MN? >=20 > =3D> Completely useless. Unless I'm missing something in your = scenario.=20 > Just write down step by step what will happen and include messages. I=20 > don't see how this can possibly be relevant to the MN. >=20 > Hesham >=20 > Hesham >=20 >>=20 >> /yuri >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Thursday, June 04, 2009 4:38 PM >> To: Yuri Ismailov; Nicolas Montavont;=20 >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of=20 >> flowbindings >>=20 >> Yuri, >>=20 >>=20 >> On 5/06/09 12:01 AM, "Yuri Ismailov" = wrote: >>=20 >>> Hesham, >>>=20 >>> I provided several scenarious which you said are invalid. This is=20 >>> where my conclusion about standpoint comes from. >>> Whether you call hints policies or rules it does not change what=20 >>> information can be provided by HA to MN. >>=20 >> =3D> It changes the outcome for the work item we're discussing. I'm=20 >> trying to come to a conclusion on this and there is a huge difference = >> between transferring policies and installing flow bindings. >>=20 >>> By sending rules HA does not install anything in MN. Likewise, MN=20 >>> does not install rules in HA, it informs HA about currently made = choices. >>> As I remember rules will not be valid until proper Ack arrival,=20 >>> which for me means that may not be instantiated at all. >>> Niether rules nor polices are specific to MIP. As I wrote those can=20 >>> be exchanged between hosts without any MIP implementation, just for=20 >>> access selection purposes. Once it was decided to make it as part of = >>> MIP protocol, I'm fine with that. Do not have any idea to discuss=20 >>> this, while personally consider that the work on rules transfer can=20 >>> very well fit into the MEXT group but as a separate work item, but=20 >>> this is not the case now, so good enough the way it is. >>> And back again, it really gets repeated, so will lead to nowhere,=20 >>> you've got my arguments and tell that the information, which I'm=20 >>> talking about, is not usefull. What can I say more? I can put you on = >>> my position and start asking questions instead of answering. So, why = >>> it is not usefull? >>=20 >> =3D> I explained why the specific information you mentioned was not=20 >> useful/useable by the MN and this is what I referred to as = unanswered. >> Because if you agree with my previous explanations then we don't need = >> to discuss it further. If you disagree you certainly didn't tell me=20 >> why. You have the charge of proof because you want to change the way=20 >> MIP works currently, that's all I'm trying to say. >>=20 >> Hesham >>=20 >>>=20 >>> /yuri >>>=20 >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Thursday, June 04, 2009 4:00 AM >>> To: Yuri Ismailov; Nicolas Montavont;=20 >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>> flowbindings >>>=20 >>> Yuri, >>>=20 >>>=20 >>>=20 >>>> Missing is additional information which may be helpful in making=20 >>>> better decision about interface selection by MN. >>>> Which information is that I wrote in my previous emails. Back to my = >>>> examples (not all, do not want to repeat myself). If HA will have=20 >>>> changed traffic shaping parameters on one of the incoming or=20 >>>> outgoing interfaces, this will be important information for MN to = know. >>>> We have agreed already that whether this information important or=20 >>>> not, benfitial or not is a matter of standpoint. >>>=20 >>> =3D> I don't agree or like to think that it's a matter of = standpoint. >>> That's why I asked you on every point you raised and compared this=20 >>> to the MN's knowledge on e2e basis. Once we have "standpoints" then=20 >>> we're getting outside the technical realm. The reason I don't think=20 >>> it's useful is that this information cannot be used by the MN to=20 >>> select a CoA. I've already stated that before and you seemed to=20 >>> agree so I don't know why you repeat this as a reason for the HA to=20 >>> install filters in the MN. Let me say it >>> again: There is no correlation between the routing on the HA's=20 >>> upstream interfaces/ISP with the MN's selection of a CoA. >>>=20 >>>> I consider that knowing more is a benefit and will help to get=20 >>>> better result. >>>>=20 >>>> My point is still the same. I see the reverse rules sending as=20 >>>> possibility to provide more information to the MN, thus make MN to=20 >>>> get to better decision about interface selection for its flows.=20 >>>> This point has not changed since the beginning of the discussion. >>>=20 >>> =3D> This is why we're not making progress IMO: >>>=20 >>> 1. The hints you refer to are not the same things as installing=20 >>> rules on the MN. Completely different information in fact. You've=20 >>> essentially proved that when you suggested that the MN can accept or = >>> reject them. So, let's not call them rules. The more direct word for = >>> what you want to send is policies >>>=20 >>> 2. You didn't provide a valid scenario that we can discuss as to why = >>> it's needed or how it could work. I've asked numerous questions in=20 >>> each email that were not answered (with the exception of the last=20 >>> email). It's not possible to progress the discussion without=20 >>> answering each others' >>> questions. You can go back through the threads and verify this. >>>=20 >>> 3. If we're sending rules from the HA to the MN and the MN can=20 >>> reject those rules then the whole exercise is pointless. You really=20 >>> want to send policies not rules. I can imagine those policies being=20 >>> one of the inputs that the MN uses to make a decision. I still fail=20 >>> to see how anything happening on the HA's upstream interfaces/ISP=20 >>> link can possibly influence the MN's decision for CoA selection.=20 >>> This is another unanswered question. >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> /yuri >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Wednesday, June 03, 2009 4:09 PM >>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>>> flowbindings >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 3/06/09 10:47 PM, "Yuri Ismailov" = wrote: >>>>=20 >>>>> Ok, see your point, however:-) >>>>>=20 >>>>> The major difference here is that your are talking about CoA=20 >>>>> selection and I'm talking about interface selection. Quite a big=20 >>>>> difference. >>>>=20 >>>> =3D> No, that's not the point really. The point is that there is no = >>>> relationship between CoA/interface selection on the MN and the=20 >>>> upstream ISP for the home network. >>>>=20 >>>>> I do not see any grounds for MN to select CoA, based on what? >>>>> Prefix length? >>>>> While selection of an interface is based on expected=20 >>>>> characteristics of the communication. Routes (up/down)link in my=20 >>>>> opinion do have impact on the characteristics and this is exactly=20 >>>>> the information missing in the MN when selecting interface. >>>>=20 >>>> =3D> There is nothing missing for the MN to make this selection. >>>> Please tell us specifically what is missing. You're changing points = >>>> on me all the time now. >>>> Lets stick to one point at a time. What's missing? >>>>=20 >>>>>=20 >>>>> Whenever, MN decides to move a flow, the reason can be anything=20 >>>>> but not which CoA it has configured on each interface. >>>>>=20 >>>>> Another thing is that MN will notice something e2e if and only if=20 >>>>> such support is implemented in the MN. >>>>=20 >>>> =3D> Of course, so what? >>>>=20 >>>> Moreover, this notice can not be made at IP layer. >>>>> TCP fights alone with all problems and never tells to any other=20 >>>>> layer what is going on. So what is left? Two options. Add this=20 >>>>> support to operating system, which makes its (support) existence=20 >>>>> questionable, or to applications, which is even more questionable. >>>>=20 >>>> =3D> It's interesting that you think it's questionable to add the=20 >>>> support to the MN's OS but not questionable to add the support to=20 >>>> the HA's OS, which will not lead to the same reliability as if it=20 >>>> were done in the MN. It doesn't make sense to me. >>>>=20 >>>>>=20 >>>>>>>=20 >>>>>>> Well, that's debatable, but this is clearly not a reason to do = anything. >>>>>>>=20 >>>>> Are you serious about that MIP may be broken because of that? >>>>=20 >>>> =3D> Yes! It's not designed to do what you want to do. Luckily, in=20 >>>> this case what you want, IMO, is broken anyway so it's not a = problem. >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> /yuri >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: Wednesday, June 03, 2009 1:15 PM >>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>> pierrick.seite@orange-ftgroup.com >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of = >>>>> flowbindings >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Still some answers, despite knowing that in your opinion they are = >>>>>> not benefits. >>>>>>=20 >>>>>> First of all MIP will not be breaked if the rules will be sent in = >>>>>> both directions. >>>>>=20 >>>>> =3D> Well, that's debatable, but this is clearly not a reason to = do=20 >>>>> anything. >>>>>=20 >>>>>>=20 >>>>>> - Access provider preferences relate to the use of backbone=20 >>>>>> provider, which may vary with the time of day. Changing backbone=20 >>>>>> provider can make quite big difference for commnication between=20 >>>>>> HA (if HA service is provided by the same access provider) and = CN(s). >>>>>> The difference can be expressed in, let's say, number of hops,=20 >>>>>> load, possibly something else. Such change is an event and may=20 >>>>>> have an impact on the overall communication. This can be told=20 >>>>>> directly to MN or HA. Direct communication to MN (if accepted as >>>>>> benefit:-)) in such case will need standardization. Communication = >>>>>> of this information to HA does not (I consider this as a = benefit). >>>>>> HA may act upon that event, and the rest you >>>>>> know: rules in reverse direction. >>>>>=20 >>>>> =3D> There is no need to _tell_ the MN anything. There are two = issues here. >>>>> First, changing network conditions are best known e2e. So the MN=20 >>>>> will know that anyway based on the traffic running between it and = the CN. >>>>> The other issue is related to cost for certain times of day. This=20 >>>>> is a routing issue in the HA and has nothing to do with which=20 >>>>> interface the MN selects. The selected CoA has zero impact on the=20 >>>>> HA's upstream selection. Completely irrelevant actually. >>>>> Of course, as far as cost on the visited link, the MN knows best. >>>>>=20 >>>>>>=20 >>>>>> - Access provider may set up different parameters for traffic=20 >>>>>> shaping for each of HA interfaces. These preferences may vary=20 >>>>>> independently of change of backbone provider but dependently on=20 >>>>>> the time of day. >>>>>> The rest you know, whether it changes somebodies opinion. >>>>>=20 >>>>> =3D> But again, this has zero effect on CoA selection. The two=20 >>>>> issues are completely orthogonal. Selecting CoA1 or CoA2 has zero=20 >>>>> impact on the HA's upstream route. >>>>>=20 >>>>>>=20 >>>>>> - I presume that in RO mode this is similar to HA mode, and I'm=20 >>>>>> in when it comes to send rules in reverse direction between CN = and MN. >>>>>> Benefits of doing that is that any change percieved by CN as=20 >>>>>> important to react upon can be expressed in proposal of new = rules. >>>>>> The sources causing changes may include but not limited to, are=20 >>>>>> user, network managemnt events, application generated events, = etc. >>>>>>=20 >>>>>> So feel free to consider this as benefits or not >>>>>=20 >>>>> =3D> You seem to think that there is a relationship between = upstream=20 >>>>> routing and CoA selection. That's not the case at all. These are=20 >>>>> two different addresses from two different networks. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>>=20 >>>>>> /yuri >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>> Sent: Wednesday, June 03, 2009 11:47 AM >>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>> pierrick.seite@orange-ftgroup.com >>>>>> Cc: mext@ietf.org >>>>>> Subject: Re: [MEXT] Important considerations for directionality=20 >>>>>> of flowbindings >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 3/06/09 7:33 PM, "Yuri Ismailov" = wrote: >>>>>>=20 >>>>>>> Hesham, >>>>>>>=20 >>>>>>> Whenever we talk about sending additional information, the=20 >>>>>>> "waste of bandwidth" can be brought up. So I do not have an=20 >>>>>>> answer for that besides speculations around it. >>>>>>=20 >>>>>> =3D> no no, I don't mean it literally, I mean that the message=20 >>>>>> doesn't do anything, i.e. Has no benefit. >>>>>>=20 >>>>>>>=20 >>>>>>> Speaking about benefits, everybody who knows the area is capable = >>>>>>> of turning things up side down. I assume it is subjective=20 >>>>>>> standpoint of considering things as benefits or disadvantages=20 >>>>>>> and all is about to agree or disagree. >>>>>>=20 >>>>>> =3D> That's fine, I'm asking for benefits in your opinion not=20 >>>>>> someone else's. >>>>>> It's impossible to discuss this if I can't see any benefits=20 >>>>>> because you didn't send any. What you sent were actions that can=20 >>>>>> be done by the HA and I responded by saying that the same (or >>>>>> more) information is available to the MN. Therefore, if you think = >>>>>> there are additional benefits to doing this in the HA then you=20 >>>>>> need to tell us. >>>>>>=20 >>>>>> The bottom line is this: MIP works by letting the MN install=20 >>>>>> bindings in the HA. If you want things to work in reverse you=20 >>>>>> need to justify it. I can't see any justifications because you're = >>>>>> not answering my questions on your scenarios. So, count me out on = >>>>>> the reverse direction :). >>>>>>=20 >>>>>>=20 >>>>>> For >>>>>>> me those I wrote about are benefits or potential benefits if you = want. >>>>>>=20 >>>>>> =3D> No you didn't. You wrote about things that can be done. Many = >>>>>> things can be done by many entities, the question is why the HA=20 >>>>>> and not the MN. >>>>>>=20 >>>>>>> One important thing in the discussion, although mentioned, but=20 >>>>>>> forgotten later is that by making rules distribution one way=20 >>>>>>> only, we do create limitation for benefits, or potential=20 >>>>>>> benefits if this sounds better. >>>>>>=20 >>>>>> =3D> Well, we won't know what we're missing unless someone tells = us. >>>>>> So far no one has mentioned the advantages of doing things in the = >>>>>> reverse direction. >>>>>> There is always something missing from a protocol (it's=20 >>>>>> engineering), the question us whether it's significant or worth=20 >>>>>> the trouble. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>>=20 >>>>>>> /yuri >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>> Sent: Wednesday, June 03, 2009 10:10 AM >>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>> Cc: mext@ietf.org >>>>>>> Subject: Re: [MEXT] Important considerations for directionality=20 >>>>>>> of flowbindings >>>>>>>=20 >>>>>>> Yuri, >>>>>>>=20 >>>>>>> I can't parse those events you refer to. I'l answer both emails = here. >>>>>>> First the events you refer to: >>>>>>>=20 >>>>>>>>> - network condition towards CN(s) >>>>>>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>>>>>=20 >>>>>>> =3D> What's the event? A change in those conditions? The MN = knows=20 >>>>>>> the conditions of the e2e path as well as or better than the HA. >>>>>>> What is the benefit of having the HA send a hint and how=20 >>>>>>> reliable is that hint anyway? >>>>>>>=20 >>>>>>>>> - Access provider (any access, not necessarily wireless) who=20 >>>>>>>>> offeres HA services preferences change >>>>>>>=20 >>>>>>> =3D> Preferences change to what?? How does it know if such = change=20 >>>>>>> works for the MN at all? This is way too vague to be able to=20 >>>>>>> discuss tradeoffs. >>>>>>>=20 >>>>>>>>> - Change of the access provider traffic to another backbone=20 >>>>>>>>> provider due to the time of the day. >>>>>>>>> - Traffic condition on HA interface, which accepts traffic=20 >>>>>>>>> from MN if MN sends on some particular local interface >>>>>>>=20 >>>>>>> =3D> These are path changes. The HA has _no idea_ how such a=20 >>>>>>> change affects each MN/CN combination and it's "hint" can cause=20 >>>>>>> more problems than it solves. BTW, if you're talking about hints = >>>>>>> then we're no longer talking about installing bindings in the=20 >>>>>>> MN. This is a different topic. MIP doesn't transfer hints, it=20 >>>>>>> pretty much sends "orders" >>>>>>> from one end to another. >>>>>>>=20 >>>>>>> Now to the actions required by the MN: >>>>>>>=20 >>>>>>>> - reject, >>>>>>>> - re-evaluate and reject >>>>>>>> - re-evaluate and accept >>>>>>>> - accept >>>>>>>=20 >>>>>>> =3D> First, by assuming that the MN can reject the "hint" as you = >>>>>>> call it you invalidate the whole argument for the HA to install = rules. >>>>>>> Rejecting a hint or even evaluating it means that the MN knows = more. >>>>>>> Therefore, the HA's hint is a complete waste of bandwidth. >>>>>>>=20 >>>>>>> I'm still confused about the _benefits_ you see here. Or are you = >>>>>>> assuming that the MN can't know those hints without the HA's=20 >>>>>>> involvement? But if you're assuming that, then how can it reject = >>>>>>> the hints? This whole proposal makes no sense to me at all. Not=20 >>>>>>> to mention the complexity you implicitly assume in order to=20 >>>>>>> generate those, hopefully reliable, hints. >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>=20 >>>>>>> On 3/06/09 5:23 PM, "Yuri Ismailov" = wrote: >>>>>>>=20 >>>>>>>> Hesham, >>>>>>>>=20 >>>>>>>> In my view these are events not scenarious. These events are=20 >>>>>>>> known by HA but not MN. If HA acts upon events, given that it=20 >>>>>>>> knows somewhat more about MN, not only IP addresses, it (HA)=20 >>>>>>>> can generate new rules and send them as hint to MN. Back again, = >>>>>>>> MN has four >>>>>>>> options: >>>>>>>>=20 >>>>>>>> The benefit will be obviously that the new rules (if accepted)=20 >>>>>>>> may llead to a better overall communication characteristics. >>>>>>>>=20 >>>>>>>> /yuri >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =3D> I'm trying to understand what you mean above. These are = all=20 >>>>>>>> scenarios, the question is: What is the benefit for the HA to=20 >>>>>>>> transfer rules? The HA will not know the path between the MN=20 >>>>>>>> and CN more than either node does. So I don't understand what=20 >>>>>>>> _benefits_ you see here. >>>>>>>>=20 >>>>>>>> Hesham >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Pretty much sure that there are more examples and I encourage=20 >>>>>>>>> to think about those not from MN point of view but rather from = >>>>>>>>> the HA service provider. >>>>>>>>>=20 >>>>>>>>> /yuri >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>> Cc: mext@ietf.org >>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>> directionality of flowbindings >>>>>>>>>=20 >>>>>>>>> Yuri, >>>>>>>>>=20 >>>>>>>>> It is just rules TRANSFER which is the matter of MIP. So=20 >>>>>>>>> where >>>>>>>>>> is the logic when saying that MN to HA rules transfer is a=20 >>>>>>>>>> practical engineering and HA to MN is an academic interest? >>>>>>>>>=20 >>>>>>>>> =3D> I think we've (I'm including myself) highlighted several=20 >>>>>>>>> reasons for why it makes little sense to transfer rules from = HA to MN. >>>>>>>>> Instead of rat-holing on theory Vs practice, you (or others=20 >>>>>>>>> advocating the other direction) need to come up with reasons=20 >>>>>>>>> for doing things this way. This way we can think like=20 >>>>>>>>> engineers about tradeoffs. >>>>>>>>> Absent that, I don't see any point in having theory Vs=20 >>>>>>>>> practice high level discussions, which will lead nowhere. >>>>>>>>>=20 >>>>>>>>> Hesham >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Regards >>>>>>>>>> Yuri >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>>> directionality of flowbindings >>>>>>>>>>=20 >>>>>>>>>> Hi Pierrick, >>>>>>>>>>=20 >>>>>>>>>> On Jun 2, 2009, at 4:11 PM,=20 >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Hi all, >>>>>>>>>>>=20 >>>>>>>>>>> Please see inline comment. >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>> Pierrick >>>>>>>>>>>=20 >>>>>>>>>>>> ________________________________________ >>>>>>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>>> De la part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 = 09:35 =C0 : >>>>>>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important=20 >>>>>>>>>>>> considerations for directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham, >>>>>>>>>>>> This is nice story and makes some sense for the discssion,=20 >>>>>>>>>>>> however some details are ommited. In your adventure with=20 >>>>>>>>>>>> the helpdesk, it (the >>>>>>>>>>>> helpdesk) is a third party service and thus your=20 >>>>>>>>>>>> conclusions make sence. >>>>>>>>>>>> Think of the situation when superior of a heldesk person=20 >>>>>>>>>>>> will tell him/her to check access point in some room. Would = >>>>>>>>>>>> it be the same reaction? I assume not. By that I mean that=20 >>>>>>>>>>>> if, for example, I'll install home agent in my home=20 >>>>>>>>>>>> network, I can make it know anything I want about MN, and=20 >>>>>>>>>>>> more intresting is that how I will do it, does not require=20 >>>>>>>>>>>> any standardization. >>>>>>>>>>>> In other words, I'm superior of my HA. >>>>>>>>>>>> This situation is not unthinkable, I personally believe=20 >>>>>>>>>>>> that this is much more efficient way of using HA=20 >>>>>>>>>>>> fnctionality as opposed to big service providers who will=20 >>>>>>>>>>>> have to fight with scalability and performance. >>>>>>>>>>>> However, one does not exclude another. >>>>>>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> The difference between policy and rules is not only a matter = >>>>>>>>>>> of conversion. A policy, is a static, or quasi-static, set=20 >>>>>>>>>>> of guidance for the MN (e.g use access network X for=20 >>>>>>>>>>> application type >>>>>>>>>>> A,...) while a rule update requires to be more dynamic. I = mean: >>>>>>>>>>> eventually a policy could be updated depending on network=20 >>>>>>>>>>> condition (e.g if X overloaded, use access network Y for=20 >>>>>>>>>>> application type A,...) but a rule reacts on local triggers = (e.g. >>>>>>>>>>> modification of the radio link >>>>>>>>>>> quality) with a shorter period of variation. So, IMHO, there = >>>>>>>>>>> is no requirement for updating policy on a short period and=20 >>>>>>>>>>> out-of-band mechanism can be used (e.g. IEEE 802.21 in push=20 >>>>>>>>>>> mode,...). >>>>>>>>>>=20 >>>>>>>>>> Fully agree! >>>>>>>>>> This is why I do not support the exchange of rules from the=20 >>>>>>>>>> HA to the MN. >>>>>>>>>> Policies may be exchanged from the HA to the MN, but MIP is=20 >>>>>>>>>> definitely not the protocol to transport them. >>>>>>>>>>=20 >>>>>>>>>> Nicolas >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> My 2 cents... >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Is there any reason to restrict where such convertion takes = place? >>>>>>>>>>>> True >>>>>>>>>>>> that a HA does not know what is going on in the access=20 >>>>>>>>>>>> network, on the other hand HA may know what is the network=20 >>>>>>>>>>>> condition between HA and correspondent node. Either of this = >>>>>>>>>>>> information is important, if not equally important. >>>>>>>>>>>> It is not really difficult to let an MN to reject rules=20 >>>>>>>>>>>> sent by HA, which in my view would be quite natural. This=20 >>>>>>>>>>>> implies that HA must follow the rules installed by MN until = >>>>>>>>>>>> explicit acceptance has been received from MN. >>>>>>>>>>>> Such procedure is very similar to an MN beahviour when=20 >>>>>>>>>>>> initiating new BU, where MN is not supposed to send any=20 >>>>>>>>>>>> traffic before BU confirmation. >>>>>>>>>>>> BTW, what is the numerical representation of "rough = consensus"? >>>>>>>>>>>> I assume is when majority is for, is it so? >>>>>>>>>>>> Yuri >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>>> On Behalf Of Hesham Soliman >>>>>>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>>>>>> To: mext >>>>>>>>>>>> Subject: [MEXT] Important considerations for directionality = >>>>>>>>>>>> of flow bindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>> I've always been a fan of the IETF's tradition of rough=20 >>>>>>>>>>>> concensus (as opposed to voting). To me, this implies that=20 >>>>>>>>>>>> you need to get your point across and get other people to=20 >>>>>>>>>>>> see that point of view. >>>>>>>>>>>> As opposed to other organisations that require their=20 >>>>>>>>>>>> members to vote and end up with rigid political positions. >>>>>>>>>>>>=20 >>>>>>>>>>>> The chairs asked us about the directionality question of=20 >>>>>>>>>>>> the flows bindings. >>>>>>>>>>>> On the charter question, I said that the charter doesn't=20 >>>>>>>>>>>> need to mention how a solution should work, but rather what = >>>>>>>>>>>> problem needs to be solved. >>>>>>>>>>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>>>>>>>>>> transferring rules "between" the MN and HA without=20 >>>>>>>>>>>> mentioning directions. >>>>>>>>>>>>=20 >>>>>>>>>>>> Nevertheless, we still need to agree on identifying the=20 >>>>>>>>>>>> requirement for the solution. And when it comes to this,=20 >>>>>>>>>>>> I'm strongly against voting and I'll practice this by=20 >>>>>>>>>>>> explaining in this email why I think rules can not be=20 >>>>>>>>>>>> transferred from the HA to the MN and that the only=20 >>>>>>>>>>>> direction that makes sense in MIP is >>>>>>>>>>>> MN->HA. I'll deliberately ignore arguments like "some=20 >>>>>>>>>>>> MN->people want >>>>>>>>>>>> this" or "an SDO wants this". They fall under the=20 >>>>>>>>>>>> "meaningless words" >>>>>>>>>>>> category and I'm incapable of discussing them because they=20 >>>>>>>>>>>> come with voting attitudes. They all need to be justified=20 >>>>>>>>>>>> if the WG wants to have a technical _discussion_. >>>>>>>>>>>>=20 >>>>>>>>>>>> Here are my reasons: >>>>>>>>>>>>=20 >>>>>>>>>>>> 1. The HA does not know whether a CoA is tied to a certain=20 >>>>>>>>>>>> access technology. It is one thing for the HA to send a=20 >>>>>>>>>>>> message saying "forward port 80 traffic on a wifi link" (a >>>>>>>>>>>> policy) and a completely different thing to say "forward=20 >>>>>>>>>>>> port 80 traffic using CoA 3ffe::1" >>>>>>>>>>>> (a rule). >>>>>>>>>>>>=20 >>>>>>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem = now? >>>>>>>>>>>> The problem is that the HA has no idea about dynamic=20 >>>>>>>>>>>> changes on that wifi link. It doesn't know if it's=20 >>>>>>>>>>>> congested, it doesn't know what application is using port=20 >>>>>>>>>>>> 80 (it doesn't have to be web >>>>>>>>>>>> traffic) or port 8000 for that matter and doesn't even know = >>>>>>>>>>>> if the AP of that wifi link works at all. >>>>>>>>>>>> Finally, it >>>>>>>>>>>> doesn't know the user's policies or other admin policies=20 >>>>>>>>>>>> for that MN. >>>>>>>>>>>> This type of information needs to be sent regularly because = >>>>>>>>>>>> it changes all the time and requires serious cross layer=20 >>>>>>>>>>>> integration including sometimes layer 8 integration! It's=20 >>>>>>>>>>>> completely impractical. >>>>>>>>>>>>=20 >>>>>>>>>>>> 3. If the HA installed rules in the MN, what happens if the = >>>>>>>>>>>> MN wants to change those rules. Say the wifi link went=20 >>>>>>>>>>>> down, or the MN's wifi interface went down and it wants to=20 >>>>>>>>>>>> move that traffic to another interface. Would the HA reject = such move? >>>>>>>>>>>> Does the MN have to justify to the HA why it needs to move=20 >>>>>>>>>>>> traffic? Does that involve writing a letter perhaps? >>>>>>>>>>>> If you say "well in that case, the HA should let the MN=20 >>>>>>>>>>>> move the traffic" >>>>>>>>>>>> then I'll ask you: what's the point of having the HA=20 >>>>>>>>>>>> install this stuff if it has no authority and how does it=20 >>>>>>>>>>>> know the reason for the MN's movement of the flow? >>>>>>>>>>>> The way to control how users do things is to incentivise=20 >>>>>>>>>>>> them with charging models and show them that things work=20 >>>>>>>>>>>> better on certain technologies, not by installing rules=20 >>>>>>>>>>>> that can't be followed. It's a broken mindset and we've=20 >>>>>>>>>>>> known that it's broken for a long time. >>>>>>>>>>>>=20 >>>>>>>>>>>> 4. Some people mentioned that the HA should be able to=20 >>>>>>>>>>>> revoke flows on the MN. I'm perfectly fine with that, just=20 >>>>>>>>>>>> extend the binding revocation draft to handle flows and the = >>>>>>>>>>>> rest is pretty straight forward. >>>>>>>>>>>>=20 >>>>>>>>>>>> Finally, I'll indulge in a true story that happened to me a = >>>>>>>>>>>> few years ago when I found that my wifi link wasn't working = >>>>>>>>>>>> in a hotel (no >>>>>>>>>>>> radio) >>>>>>>>>>>> and called the help desk. He insisted that the link was up=20 >>>>>>>>>>>> an I insisted that it wasn't. When I asked him to tell me=20 >>>>>>>>>>>> how he knows the link is up he said: I can ping the AP! Of=20 >>>>>>>>>>>> course after another >>>>>>>>>>>> 5 minutes of trying to convince him that pinging the AP=20 >>>>>>>>>>>> doesn't mean the radio is actually working he sent someone=20 >>>>>>>>>>>> to the hotel who in turn realised that the radio was not = working. >>>>>>>>>>>> For those people who want rules to be transferred from the=20 >>>>>>>>>>>> HA to the MN, please think of your HA as this help desk=20 >>>>>>>>>>>> person, i.e. >>>>>>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>>>>>=20 >>>>>>>>>>>> I hope this helps with the realisation that decisions can't = >>>>>>>>>>>> be made here based on voting and that there is little merit = >>>>>>>>>>>> to transferring rules from the HA to the MN. Policies can=20 >>>>>>>>>>>> be transferred without any problems, but not rules. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> MEXT mailing list >>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From hesham@elevatemobile.com Mon Jun 8 05:00:46 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82A03A6846 for ; Mon, 8 Jun 2009 05:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 KjXLIv+puOgW for ; Mon, 8 Jun 2009 05:00:43 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 0EB153A6829 for ; Mon, 8 Jun 2009 05:00:42 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MDdWh-0001UU-Mt; Mon, 08 Jun 2009 22:00:34 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Mon, 08 Jun 2009 22:00:24 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiih In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 12:00:46 -0000 Yuri,=20 I think we're getting close here. On 8/06/09 6:29 PM, "Yuri Ismailov" wrote: > Hesham, It looks like that the only point of disagreement is about changi= ng HA > and mapping between HA and access. > Some explanations of what I mean below: >=20 >=20 > 1. Changing HA. > As it follows from group charter change of HA is in the plans of MEXT WG.= I > assume that this is going to be a separate work item because the reason > specified for that is very specific and relates to deployment more than t= o > flow mobility. Do not want to speculate, about this right now but the cha= nge > of HA does not necessarily means change of rules. > So the proposal is to not to discuss change of HA as you suggested. =3D> Agreed. >=20 > 2. In my example I do not mean change of HA as an explicit procedure spec= ified > separately. One confirmation to that is that single HA for all interfaces= is > included and valid option. Based on the HA -> MN exchange, the MN may per= form > interface selection procedure and may choose another interface for some > flow(s). In multiple HA case it will result of the rules update MN -> HA = to > the HA which is relevant for the new interface chosen for flows. Please > notice, There is nothing about HA change, only about interface selection. =3D> Yes but I still think you're talking about something else. The interface you're talking about seems to be associated with the HoA. This is the only case where I can see the relevance of HA hints (not rules). The interfaces I'm talking about and discussed in the context of flow bindings are those associated with CoAs. There is nothing coming from the HA about its links ...etc that can have any impact on CoA selection. >=20 > 3. I do not map HA and access. It is allowed for any access provider to o= ffer > HA service and once this is the case it will be so. Thus an MN can have > multiple HA configured for the use on different interfaces. =3D> Good, we agree on that too. Hesham >=20 > Regards > Yuri >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Friday, June 05, 2009 4:18 PM > To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of > flowbindings >=20 >=20 >=20 >> First is that I assume that we have simulteneous multiaccess in mind, >> i.e. MN has more than one interface to choose from for its flows. If >> this is not the case then I will stop the discussion. This assumption >> is based on the fact that we are (I hope at least) discussing flow mobil= ity. >=20 > =3D> Sure. >=20 >>=20 >> Secondly, I consider that MN chooses an interface but not CoA. I gave >> a though about that and did not come up with any information which can >> be derived from CoA in order to choose it. An interface has at least >> expected characteristics, thus can be a subject of choice. Any >> clarification about that would be appreciated. > =3D> An application would choose an interface, but of course the IP stack > selects the corresponding address. I'm sure there is no disagreement ther= e. >=20 >>=20 >> Next assumptions are about possible configurations of HA >> - Single HA for all interfaces configured in the mobile. HA can belong >> to any of the access providers of each of access technology used by MN. >=20 > =3D> Ok. >=20 >>=20 >> - One HA per access or set of accesses, which is subset of all access >> techologies presented or potentially may be presented (detached >> devices) in MN. >=20 > =3D> Now you're getting into a different problem space from flow mobility. > This is why I wanted you to break the scenario down. We are not dealing w= ith > multiple HoAs in this work item, we're dealing with multiple CoAs, i.e. O= ne > HoA. >=20 >> Anticipating numerous questions about that can say that I looked at >> such configuration and did not find anything strange with it, i.e. (1) >> it works, >> (2) it does not require any change to MIP or any other of its >> extensions. (3) Configuration is performed per interface and does not >> introduce any ambiguities. (4) it is natural for access provider to offe= r HA >> service. >=20 > =3D> Yes of course it works but as I read this I'm guessing that you want t= he MN > to change HoA. This is not the problem we're discussing in this WG. > Another issue, I'm not comfortable with the wording of "HA per access" > because they're not tied to access. Let's just say there are multiple Has= and > not associate it with an access. >=20 >>=20 >> - "Residential" HA. Assumption is that it can be either one of HA's or >> a single HA for all types of accesses. This is the matter of MN >> configuration. >> "Residential". >=20 > =3D> Please don't tie HA to access. >=20 >>=20 >> - Any HA may have multiple interfaces, e.g. "residential" HA may be >> connected to mobile broadband, DSL, etc. >=20 > =3D> sure >=20 >>=20 >> Next assumption comes from the example (e.g. latest one) >> - Traffic shaping is applied in both directions (up/down) link (in >> practice this is the case). >> - Traffic shaping (TS) is applied to user subscription. In other words >> TS is applied to packets belonging to a particular subscription but >> not to an aggregated traffic on gateway interfaces. HA is not >> necessary (however, nothing prevents from that) a gateway where TS is >> applied. >>=20 >>=20 >> I hope that I have not missed something, although it may be possible. >> If we can agree on that or correct if something is wrong here and >> agree later then we know how to proceed further on >=20 > =3D> Your scenario is fine (with the wording changes for tying Has to acces= s). > But I want to pre-empt any suggestion that the HA will tell the MN to use= a > different HoA. This is very possible but it's not the problem being discu= ssed > here. It may well be something for charter discussion but it has zero imp= act > on flow bindings for multiple CoAs. >=20 > Hesham >=20 >>=20 >> /yuri >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Friday, June 05, 2009 11:37 AM >> To: Yuri Ismailov; Nicolas Montavont; >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of >> flowbindings >>=20 >> Yuri, >>=20 >>=20 >>> Still not clear for me why you call scenarious invalid? >>> Some broadband providers (this is used in practice) have quota on the >>> amount of traffic sent by users. Once quota is exceeded provider >>> downgardes outgoing traffic from its network to 64Kbs (this figure is >>> the real example from real provider). Such combination of to paths, >>> where one is high speed, lets say 10 Mbs and another one is 64Kbs is >>> quite crusual to apps running on top of TCP. >>> Not for all types of traffic though. >>=20 >> =3D> Yes I know the scenario but I keep saying to you that the change in >> upstream routing in the HA has nothing to do with CoA selection by the >> MN in the visited network. If anything, you want the MN to change it's >> HoA depending on how the switch to another upstream ISP works. It's a >> completely irrelevant issue to this discussion. Do you agree? If not >> why not? I really want to see an answer to this point. >>=20 >> =20 >>=20 >>=20 >>>=20 >>> MN can not know about this situation. Nobody will send this >>> information to MN. >>=20 >> =3D> Yes and if it knows what will it do??? If you can answer that you >> will fix the deadlock we have. >>=20 >>> That means that MN will choose its interfaces based on its knowledge >>> about 10Mbs link capabilities. >>=20 >> =3D> You're talking about two different things. The MN doesn't choose >> the HA's outgoing interface! What am I missing? >>=20 >> Obtaining this isnformation from HA is quite >>> significant to make a better decision about choice of interfaces for >>> its flows. >>> This is concrete example of what happens in the reality. >>> Do you consider that this information will be useless for MN? >>=20 >> =3D> Completely useless. Unless I'm missing something in your scenario. >> Just write down step by step what will happen and include messages. I >> don't see how this can possibly be relevant to the MN. >>=20 >> Hesham >>=20 >> Hesham >>=20 >>>=20 >>> /yuri >>>=20 >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Thursday, June 04, 2009 4:38 PM >>> To: Yuri Ismailov; Nicolas Montavont; >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of >>> flowbindings >>>=20 >>> Yuri, >>>=20 >>>=20 >>> On 5/06/09 12:01 AM, "Yuri Ismailov" wrote= : >>>=20 >>>> Hesham, >>>>=20 >>>> I provided several scenarious which you said are invalid. This is >>>> where my conclusion about standpoint comes from. >>>> Whether you call hints policies or rules it does not change what >>>> information can be provided by HA to MN. >>>=20 >>> =3D> It changes the outcome for the work item we're discussing. I'm >>> trying to come to a conclusion on this and there is a huge difference >>> between transferring policies and installing flow bindings. >>>=20 >>>> By sending rules HA does not install anything in MN. Likewise, MN >>>> does not install rules in HA, it informs HA about currently made choic= es. >>>> As I remember rules will not be valid until proper Ack arrival, >>>> which for me means that may not be instantiated at all. >>>> Niether rules nor polices are specific to MIP. As I wrote those can >>>> be exchanged between hosts without any MIP implementation, just for >>>> access selection purposes. Once it was decided to make it as part of >>>> MIP protocol, I'm fine with that. Do not have any idea to discuss >>>> this, while personally consider that the work on rules transfer can >>>> very well fit into the MEXT group but as a separate work item, but >>>> this is not the case now, so good enough the way it is. >>>> And back again, it really gets repeated, so will lead to nowhere, >>>> you've got my arguments and tell that the information, which I'm >>>> talking about, is not usefull. What can I say more? I can put you on >>>> my position and start asking questions instead of answering. So, why >>>> it is not usefull? >>>=20 >>> =3D> I explained why the specific information you mentioned was not >>> useful/useable by the MN and this is what I referred to as unanswered. >>> Because if you agree with my previous explanations then we don't need >>> to discuss it further. If you disagree you certainly didn't tell me >>> why. You have the charge of proof because you want to change the way >>> MIP works currently, that's all I'm trying to say. >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> /yuri >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Thursday, June 04, 2009 4:00 AM >>>> To: Yuri Ismailov; Nicolas Montavont; >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of >>>> flowbindings >>>>=20 >>>> Yuri, >>>>=20 >>>>=20 >>>>=20 >>>>> Missing is additional information which may be helpful in making >>>>> better decision about interface selection by MN. >>>>> Which information is that I wrote in my previous emails. Back to my >>>>> examples (not all, do not want to repeat myself). If HA will have >>>>> changed traffic shaping parameters on one of the incoming or >>>>> outgoing interfaces, this will be important information for MN to kno= w. >>>>> We have agreed already that whether this information important or >>>>> not, benfitial or not is a matter of standpoint. >>>>=20 >>>> =3D> I don't agree or like to think that it's a matter of standpoint. >>>> That's why I asked you on every point you raised and compared this >>>> to the MN's knowledge on e2e basis. Once we have "standpoints" then >>>> we're getting outside the technical realm. The reason I don't think >>>> it's useful is that this information cannot be used by the MN to >>>> select a CoA. I've already stated that before and you seemed to >>>> agree so I don't know why you repeat this as a reason for the HA to >>>> install filters in the MN. Let me say it >>>> again: There is no correlation between the routing on the HA's >>>> upstream interfaces/ISP with the MN's selection of a CoA. >>>>=20 >>>>> I consider that knowing more is a benefit and will help to get >>>>> better result. >>>>>=20 >>>>> My point is still the same. I see the reverse rules sending as >>>>> possibility to provide more information to the MN, thus make MN to >>>>> get to better decision about interface selection for its flows. >>>>> This point has not changed since the beginning of the discussion. >>>>=20 >>>> =3D> This is why we're not making progress IMO: >>>>=20 >>>> 1. The hints you refer to are not the same things as installing >>>> rules on the MN. Completely different information in fact. You've >>>> essentially proved that when you suggested that the MN can accept or >>>> reject them. So, let's not call them rules. The more direct word for >>>> what you want to send is policies >>>>=20 >>>> 2. You didn't provide a valid scenario that we can discuss as to why >>>> it's needed or how it could work. I've asked numerous questions in >>>> each email that were not answered (with the exception of the last >>>> email). It's not possible to progress the discussion without >>>> answering each others' >>>> questions. You can go back through the threads and verify this. >>>>=20 >>>> 3. If we're sending rules from the HA to the MN and the MN can >>>> reject those rules then the whole exercise is pointless. You really >>>> want to send policies not rules. I can imagine those policies being >>>> one of the inputs that the MN uses to make a decision. I still fail >>>> to see how anything happening on the HA's upstream interfaces/ISP >>>> link can possibly influence the MN's decision for CoA selection. >>>> This is another unanswered question. >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> /yuri >>>>>=20 >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: Wednesday, June 03, 2009 4:09 PM >>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>> pierrick.seite@orange-ftgroup.com >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of >>>>> flowbindings >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 3/06/09 10:47 PM, "Yuri Ismailov" wro= te: >>>>>=20 >>>>>> Ok, see your point, however:-) >>>>>>=20 >>>>>> The major difference here is that your are talking about CoA >>>>>> selection and I'm talking about interface selection. Quite a big >>>>>> difference. >>>>>=20 >>>>> =3D> No, that's not the point really. The point is that there is no >>>>> relationship between CoA/interface selection on the MN and the >>>>> upstream ISP for the home network. >>>>>=20 >>>>>> I do not see any grounds for MN to select CoA, based on what? >>>>>> Prefix length? >>>>>> While selection of an interface is based on expected >>>>>> characteristics of the communication. Routes (up/down)link in my >>>>>> opinion do have impact on the characteristics and this is exactly >>>>>> the information missing in the MN when selecting interface. >>>>>=20 >>>>> =3D> There is nothing missing for the MN to make this selection. >>>>> Please tell us specifically what is missing. You're changing points >>>>> on me all the time now. >>>>> Lets stick to one point at a time. What's missing? >>>>>=20 >>>>>>=20 >>>>>> Whenever, MN decides to move a flow, the reason can be anything >>>>>> but not which CoA it has configured on each interface. >>>>>>=20 >>>>>> Another thing is that MN will notice something e2e if and only if >>>>>> such support is implemented in the MN. >>>>>=20 >>>>> =3D> Of course, so what? >>>>>=20 >>>>> Moreover, this notice can not be made at IP layer. >>>>>> TCP fights alone with all problems and never tells to any other >>>>>> layer what is going on. So what is left? Two options. Add this >>>>>> support to operating system, which makes its (support) existence >>>>>> questionable, or to applications, which is even more questionable. >>>>>=20 >>>>> =3D> It's interesting that you think it's questionable to add the >>>>> support to the MN's OS but not questionable to add the support to >>>>> the HA's OS, which will not lead to the same reliability as if it >>>>> were done in the MN. It doesn't make sense to me. >>>>>=20 >>>>>>=20 >>>>>>>>=20 >>>>>>>> Well, that's debatable, but this is clearly not a reason to do >>>>>>>> anything. >>>>>>>>=20 >>>>>> Are you serious about that MIP may be broken because of that? >>>>>=20 >>>>> =3D> Yes! It's not designed to do what you want to do. Luckily, in >>>>> this case what you want, IMO, is broken anyway so it's not a problem. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>>=20 >>>>>> /yuri >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>> Sent: Wednesday, June 03, 2009 1:15 PM >>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>> pierrick.seite@orange-ftgroup.com >>>>>> Cc: mext@ietf.org >>>>>> Subject: Re: [MEXT] Important considerations for directionality of >>>>>> flowbindings >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Still some answers, despite knowing that in your opinion they are >>>>>>> not benefits. >>>>>>>=20 >>>>>>> First of all MIP will not be breaked if the rules will be sent in >>>>>>> both directions. >>>>>>=20 >>>>>> =3D> Well, that's debatable, but this is clearly not a reason to do >>>>>> anything. >>>>>>=20 >>>>>>>=20 >>>>>>> - Access provider preferences relate to the use of backbone >>>>>>> provider, which may vary with the time of day. Changing backbone >>>>>>> provider can make quite big difference for commnication between >>>>>>> HA (if HA service is provided by the same access provider) and CN(s= ). >>>>>>> The difference can be expressed in, let's say, number of hops, >>>>>>> load, possibly something else. Such change is an event and may >>>>>>> have an impact on the overall communication. This can be told >>>>>>> directly to MN or HA. Direct communication to MN (if accepted as >>>>>>> benefit:-)) in such case will need standardization. Communication >>>>>>> of this information to HA does not (I consider this as a benefit). >>>>>>> HA may act upon that event, and the rest you >>>>>>> know: rules in reverse direction. >>>>>>=20 >>>>>> =3D> There is no need to _tell_ the MN anything. There are two issues = here. >>>>>> First, changing network conditions are best known e2e. So the MN >>>>>> will know that anyway based on the traffic running between it and th= e CN. >>>>>> The other issue is related to cost for certain times of day. This >>>>>> is a routing issue in the HA and has nothing to do with which >>>>>> interface the MN selects. The selected CoA has zero impact on the >>>>>> HA's upstream selection. Completely irrelevant actually. >>>>>> Of course, as far as cost on the visited link, the MN knows best. >>>>>>=20 >>>>>>>=20 >>>>>>> - Access provider may set up different parameters for traffic >>>>>>> shaping for each of HA interfaces. These preferences may vary >>>>>>> independently of change of backbone provider but dependently on >>>>>>> the time of day. >>>>>>> The rest you know, whether it changes somebodies opinion. >>>>>>=20 >>>>>> =3D> But again, this has zero effect on CoA selection. The two >>>>>> issues are completely orthogonal. Selecting CoA1 or CoA2 has zero >>>>>> impact on the HA's upstream route. >>>>>>=20 >>>>>>>=20 >>>>>>> - I presume that in RO mode this is similar to HA mode, and I'm >>>>>>> in when it comes to send rules in reverse direction between CN and = MN. >>>>>>> Benefits of doing that is that any change percieved by CN as >>>>>>> important to react upon can be expressed in proposal of new rules. >>>>>>> The sources causing changes may include but not limited to, are >>>>>>> user, network managemnt events, application generated events, etc. >>>>>>>=20 >>>>>>> So feel free to consider this as benefits or not >>>>>>=20 >>>>>> =3D> You seem to think that there is a relationship between upstream >>>>>> routing and CoA selection. That's not the case at all. These are >>>>>> two different addresses from two different networks. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>>=20 >>>>>>> /yuri >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>> Sent: Wednesday, June 03, 2009 11:47 AM >>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>> Cc: mext@ietf.org >>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>> of flowbindings >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 3/06/09 7:33 PM, "Yuri Ismailov" wr= ote: >>>>>>>=20 >>>>>>>> Hesham, >>>>>>>>=20 >>>>>>>> Whenever we talk about sending additional information, the >>>>>>>> "waste of bandwidth" can be brought up. So I do not have an >>>>>>>> answer for that besides speculations around it. >>>>>>>=20 >>>>>>> =3D> no no, I don't mean it literally, I mean that the message >>>>>>> doesn't do anything, i.e. Has no benefit. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Speaking about benefits, everybody who knows the area is capable >>>>>>>> of turning things up side down. I assume it is subjective >>>>>>>> standpoint of considering things as benefits or disadvantages >>>>>>>> and all is about to agree or disagree. >>>>>>>=20 >>>>>>> =3D> That's fine, I'm asking for benefits in your opinion not >>>>>>> someone else's. >>>>>>> It's impossible to discuss this if I can't see any benefits >>>>>>> because you didn't send any. What you sent were actions that can >>>>>>> be done by the HA and I responded by saying that the same (or >>>>>>> more) information is available to the MN. Therefore, if you think >>>>>>> there are additional benefits to doing this in the HA then you >>>>>>> need to tell us. >>>>>>>=20 >>>>>>> The bottom line is this: MIP works by letting the MN install >>>>>>> bindings in the HA. If you want things to work in reverse you >>>>>>> need to justify it. I can't see any justifications because you're >>>>>>> not answering my questions on your scenarios. So, count me out on >>>>>>> the reverse direction :). >>>>>>>=20 >>>>>>>=20 >>>>>>> For >>>>>>>> me those I wrote about are benefits or potential benefits if you w= ant. >>>>>>>=20 >>>>>>> =3D> No you didn't. You wrote about things that can be done. Many >>>>>>> things can be done by many entities, the question is why the HA >>>>>>> and not the MN. >>>>>>>=20 >>>>>>>> One important thing in the discussion, although mentioned, but >>>>>>>> forgotten later is that by making rules distribution one way >>>>>>>> only, we do create limitation for benefits, or potential >>>>>>>> benefits if this sounds better. >>>>>>>=20 >>>>>>> =3D> Well, we won't know what we're missing unless someone tells us. >>>>>>> So far no one has mentioned the advantages of doing things in the >>>>>>> reverse direction. >>>>>>> There is always something missing from a protocol (it's >>>>>>> engineering), the question us whether it's significant or worth >>>>>>> the trouble. >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>>=20 >>>>>>>> /yuri >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>> Sent: Wednesday, June 03, 2009 10:10 AM >>>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>> Cc: mext@ietf.org >>>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>>> of flowbindings >>>>>>>>=20 >>>>>>>> Yuri, >>>>>>>>=20 >>>>>>>> I can't parse those events you refer to. I'l answer both emails he= re. >>>>>>>> First the events you refer to: >>>>>>>>=20 >>>>>>>>>> - network condition towards CN(s) >>>>>>>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>>>>>>=20 >>>>>>>> =3D> What's the event? A change in those conditions? The MN knows >>>>>>>> the conditions of the e2e path as well as or better than the HA. >>>>>>>> What is the benefit of having the HA send a hint and how >>>>>>>> reliable is that hint anyway? >>>>>>>>=20 >>>>>>>>>> - Access provider (any access, not necessarily wireless) who >>>>>>>>>> offeres HA services preferences change >>>>>>>>=20 >>>>>>>> =3D> Preferences change to what?? How does it know if such change >>>>>>>> works for the MN at all? This is way too vague to be able to >>>>>>>> discuss tradeoffs. >>>>>>>>=20 >>>>>>>>>> - Change of the access provider traffic to another backbone >>>>>>>>>> provider due to the time of the day. >>>>>>>>>> - Traffic condition on HA interface, which accepts traffic >>>>>>>>>> from MN if MN sends on some particular local interface >>>>>>>>=20 >>>>>>>> =3D> These are path changes. The HA has _no idea_ how such a >>>>>>>> change affects each MN/CN combination and it's "hint" can cause >>>>>>>> more problems than it solves. BTW, if you're talking about hints >>>>>>>> then we're no longer talking about installing bindings in the >>>>>>>> MN. This is a different topic. MIP doesn't transfer hints, it >>>>>>>> pretty much sends "orders" >>>>>>>> from one end to another. >>>>>>>>=20 >>>>>>>> Now to the actions required by the MN: >>>>>>>>=20 >>>>>>>>> - reject, >>>>>>>>> - re-evaluate and reject >>>>>>>>> - re-evaluate and accept >>>>>>>>> - accept >>>>>>>>=20 >>>>>>>> =3D> First, by assuming that the MN can reject the "hint" as you >>>>>>>> call it you invalidate the whole argument for the HA to install ru= les. >>>>>>>> Rejecting a hint or even evaluating it means that the MN knows mor= e. >>>>>>>> Therefore, the HA's hint is a complete waste of bandwidth. >>>>>>>>=20 >>>>>>>> I'm still confused about the _benefits_ you see here. Or are you >>>>>>>> assuming that the MN can't know those hints without the HA's >>>>>>>> involvement? But if you're assuming that, then how can it reject >>>>>>>> the hints? This whole proposal makes no sense to me at all. Not >>>>>>>> to mention the complexity you implicitly assume in order to >>>>>>>> generate those, hopefully reliable, hints. >>>>>>>>=20 >>>>>>>> Hesham >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 3/06/09 5:23 PM, "Yuri Ismailov" w= rote: >>>>>>>>=20 >>>>>>>>> Hesham, >>>>>>>>>=20 >>>>>>>>> In my view these are events not scenarious. These events are >>>>>>>>> known by HA but not MN. If HA acts upon events, given that it >>>>>>>>> knows somewhat more about MN, not only IP addresses, it (HA) >>>>>>>>> can generate new rules and send them as hint to MN. Back again, >>>>>>>>> MN has four >>>>>>>>> options: >>>>>>>>>=20 >>>>>>>>> The benefit will be obviously that the new rules (if accepted) >>>>>>>>> may llead to a better overall communication characteristics. >>>>>>>>>=20 >>>>>>>>> /yuri >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> =3D> I'm trying to understand what you mean above. These are all >>>>>>>>> scenarios, the question is: What is the benefit for the HA to >>>>>>>>> transfer rules? The HA will not know the path between the MN >>>>>>>>> and CN more than either node does. So I don't understand what >>>>>>>>> _benefits_ you see here. >>>>>>>>>=20 >>>>>>>>> Hesham >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Pretty much sure that there are more examples and I encourage >>>>>>>>>> to think about those not from MN point of view but rather from >>>>>>>>>> the HA service provider. >>>>>>>>>>=20 >>>>>>>>>> /yuri >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>>> Cc: mext@ietf.org >>>>>>>>>> Subject: Re: [MEXT] Important considerations for >>>>>>>>>> directionality of flowbindings >>>>>>>>>>=20 >>>>>>>>>> Yuri, >>>>>>>>>>=20 >>>>>>>>>> It is just rules TRANSFER which is the matter of MIP. So >>>>>>>>>> where >>>>>>>>>>> is the logic when saying that MN to HA rules transfer is a >>>>>>>>>>> practical engineering and HA to MN is an academic interest? >>>>>>>>>>=20 >>>>>>>>>> =3D> I think we've (I'm including myself) highlighted several >>>>>>>>>> reasons for why it makes little sense to transfer rules from HA = to >>>>>>>>>> MN. >>>>>>>>>> Instead of rat-holing on theory Vs practice, you (or others >>>>>>>>>> advocating the other direction) need to come up with reasons >>>>>>>>>> for doing things this way. This way we can think like >>>>>>>>>> engineers about tradeoffs. >>>>>>>>>> Absent that, I don't see any point in having theory Vs >>>>>>>>>> practice high level discussions, which will lead nowhere. >>>>>>>>>>=20 >>>>>>>>>> Hesham >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Regards >>>>>>>>>>> Yuri >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>>>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>>>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>>>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>>>>>>> Subject: Re: [MEXT] Important considerations for >>>>>>>>>>> directionality of flowbindings >>>>>>>>>>>=20 >>>>>>>>>>> Hi Pierrick, >>>>>>>>>>>=20 >>>>>>>>>>> On Jun 2, 2009, at 4:11 PM, >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>> Please see inline comment. >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>> Pierrick >>>>>>>>>>>>=20 >>>>>>>>>>>> ________________________________________ >>>>>>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] >>>>>>>>>>>> De la part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:3= 5 =C0 : >>>>>>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important >>>>>>>>>>>> considerations for directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham, >>>>>>>>>>>> This is nice story and makes some sense for the discssion, >>>>>>>>>>>> however some details are ommited. In your adventure with >>>>>>>>>>>> the helpdesk, it (the >>>>>>>>>>>> helpdesk) is a third party service and thus your >>>>>>>>>>>> conclusions make sence. >>>>>>>>>>>> Think of the situation when superior of a heldesk person >>>>>>>>>>>> will tell him/her to check access point in some room. Would >>>>>>>>>>>> it be the same reaction? I assume not. By that I mean that >>>>>>>>>>>> if, for example, I'll install home agent in my home >>>>>>>>>>>> network, I can make it know anything I want about MN, and >>>>>>>>>>>> more intresting is that how I will do it, does not require >>>>>>>>>>>> any standardization. >>>>>>>>>>>> In other words, I'm superior of my HA. >>>>>>>>>>>> This situation is not unthinkable, I personally believe >>>>>>>>>>>> that this is much more efficient way of using HA >>>>>>>>>>>> fnctionality as opposed to big service providers who will >>>>>>>>>>>> have to fight with scalability and performance. >>>>>>>>>>>> However, one does not exclude another. >>>>>>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> The difference between policy and rules is not only a matter >>>>>>>>>>>> of conversion. A policy, is a static, or quasi-static, set >>>>>>>>>>>> of guidance for the MN (e.g use access network X for >>>>>>>>>>>> application type >>>>>>>>>>>> A,...) while a rule update requires to be more dynamic. I mean= : >>>>>>>>>>>> eventually a policy could be updated depending on network >>>>>>>>>>>> condition (e.g if X overloaded, use access network Y for >>>>>>>>>>>> application type A,...) but a rule reacts on local triggers (e= .g. >>>>>>>>>>>> modification of the radio link >>>>>>>>>>>> quality) with a shorter period of variation. So, IMHO, there >>>>>>>>>>>> is no requirement for updating policy on a short period and >>>>>>>>>>>> out-of-band mechanism can be used (e.g. IEEE 802.21 in push >>>>>>>>>>>> mode,...). >>>>>>>>>>>=20 >>>>>>>>>>> Fully agree! >>>>>>>>>>> This is why I do not support the exchange of rules from the >>>>>>>>>>> HA to the MN. >>>>>>>>>>> Policies may be exchanged from the HA to the MN, but MIP is >>>>>>>>>>> definitely not the protocol to transport them. >>>>>>>>>>>=20 >>>>>>>>>>> Nicolas >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> My 2 cents... >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Is there any reason to restrict where such convertion takes pl= ace? >>>>>>>>>>>> True >>>>>>>>>>>> that a HA does not know what is going on in the access >>>>>>>>>>>> network, on the other hand HA may know what is the network >>>>>>>>>>>> condition between HA and correspondent node. Either of this >>>>>>>>>>>> information is important, if not equally important. >>>>>>>>>>>> It is not really difficult to let an MN to reject rules >>>>>>>>>>>> sent by HA, which in my view would be quite natural. This >>>>>>>>>>>> implies that HA must follow the rules installed by MN until >>>>>>>>>>>> explicit acceptance has been received from MN. >>>>>>>>>>>> Such procedure is very similar to an MN beahviour when=20 >>>>>>>>>>>> initiating new BU, where MN is not supposed to send any=20 >>>>>>>>>>>> traffic before BU confirmation. >>>>>>>>>>>> BTW, what is the numerical representation of "rough consensus"= ? >>>>>>>>>>>> I assume is when majority is for, is it so? >>>>>>>>>>>> Yuri >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>>> On Behalf Of Hesham Soliman >>>>>>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>>>>>> To: mext >>>>>>>>>>>> Subject: [MEXT] Important considerations for directionality=20 >>>>>>>>>>>> of flow bindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>> I've always been a fan of the IETF's tradition of rough=20 >>>>>>>>>>>> concensus (as opposed to voting). To me, this implies that=20 >>>>>>>>>>>> you need to get your point across and get other people to=20 >>>>>>>>>>>> see that point of view. >>>>>>>>>>>> As opposed to other organisations that require their=20 >>>>>>>>>>>> members to vote and end up with rigid political positions. >>>>>>>>>>>>=20 >>>>>>>>>>>> The chairs asked us about the directionality question of=20 >>>>>>>>>>>> the flows bindings. >>>>>>>>>>>> On the charter question, I said that the charter doesn't=20 >>>>>>>>>>>> need to mention how a solution should work, but rather what=20 >>>>>>>>>>>> problem needs to be solved. >>>>>>>>>>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>>>>>>>>>> transferring rules "between" the MN and HA without=20 >>>>>>>>>>>> mentioning directions. >>>>>>>>>>>>=20 >>>>>>>>>>>> Nevertheless, we still need to agree on identifying the=20 >>>>>>>>>>>> requirement for the solution. And when it comes to this,=20 >>>>>>>>>>>> I'm strongly against voting and I'll practice this by=20 >>>>>>>>>>>> explaining in this email why I think rules can not be=20 >>>>>>>>>>>> transferred from the HA to the MN and that the only=20 >>>>>>>>>>>> direction that makes sense in MIP is >>>>>>>>>>>> MN->HA. I'll deliberately ignore arguments like "some=20 >>>>>>>>>>>> MN->people want >>>>>>>>>>>> this" or "an SDO wants this". They fall under the=20 >>>>>>>>>>>> "meaningless words" >>>>>>>>>>>> category and I'm incapable of discussing them because they=20 >>>>>>>>>>>> come with voting attitudes. They all need to be justified=20 >>>>>>>>>>>> if the WG wants to have a technical _discussion_. >>>>>>>>>>>>=20 >>>>>>>>>>>> Here are my reasons: >>>>>>>>>>>>=20 >>>>>>>>>>>> 1. The HA does not know whether a CoA is tied to a certain=20 >>>>>>>>>>>> access technology. It is one thing for the HA to send a=20 >>>>>>>>>>>> message saying "forward port 80 traffic on a wifi link" (a >>>>>>>>>>>> policy) and a completely different thing to say "forward=20 >>>>>>>>>>>> port 80 traffic using CoA 3ffe::1" >>>>>>>>>>>> (a rule). >>>>>>>>>>>>=20 >>>>>>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem now? >>>>>>>>>>>> The problem is that the HA has no idea about dynamic=20 >>>>>>>>>>>> changes on that wifi link. It doesn't know if it's=20 >>>>>>>>>>>> congested, it doesn't know what application is using port=20 >>>>>>>>>>>> 80 (it doesn't have to be web >>>>>>>>>>>> traffic) or port 8000 for that matter and doesn't even know=20 >>>>>>>>>>>> if the AP of that wifi link works at all. >>>>>>>>>>>> Finally, it >>>>>>>>>>>> doesn't know the user's policies or other admin policies=20 >>>>>>>>>>>> for that MN. >>>>>>>>>>>> This type of information needs to be sent regularly because=20 >>>>>>>>>>>> it changes all the time and requires serious cross layer=20 >>>>>>>>>>>> integration including sometimes layer 8 integration! It's=20 >>>>>>>>>>>> completely impractical. >>>>>>>>>>>>=20 >>>>>>>>>>>> 3. If the HA installed rules in the MN, what happens if the=20 >>>>>>>>>>>> MN wants to change those rules. Say the wifi link went=20 >>>>>>>>>>>> down, or the MN's wifi interface went down and it wants to=20 >>>>>>>>>>>> move that traffic to another interface. Would the HA reject su= ch=20 >>>>>>>>>>>> move? >>>>>>>>>>>> Does the MN have to justify to the HA why it needs to move=20 >>>>>>>>>>>> traffic? Does that involve writing a letter perhaps? >>>>>>>>>>>> If you say "well in that case, the HA should let the MN=20 >>>>>>>>>>>> move the traffic" >>>>>>>>>>>> then I'll ask you: what's the point of having the HA=20 >>>>>>>>>>>> install this stuff if it has no authority and how does it=20 >>>>>>>>>>>> know the reason for the MN's movement of the flow? >>>>>>>>>>>> The way to control how users do things is to incentivise=20 >>>>>>>>>>>> them with charging models and show them that things work=20 >>>>>>>>>>>> better on certain technologies, not by installing rules=20 >>>>>>>>>>>> that can't be followed. It's a broken mindset and we've=20 >>>>>>>>>>>> known that it's broken for a long time. >>>>>>>>>>>>=20 >>>>>>>>>>>> 4. Some people mentioned that the HA should be able to=20 >>>>>>>>>>>> revoke flows on the MN. I'm perfectly fine with that, just=20 >>>>>>>>>>>> extend the binding revocation draft to handle flows and the=20 >>>>>>>>>>>> rest is pretty straight forward. >>>>>>>>>>>>=20 >>>>>>>>>>>> Finally, I'll indulge in a true story that happened to me a=20 >>>>>>>>>>>> few years ago when I found that my wifi link wasn't working=20 >>>>>>>>>>>> in a hotel (no >>>>>>>>>>>> radio) >>>>>>>>>>>> and called the help desk. He insisted that the link was up=20 >>>>>>>>>>>> an I insisted that it wasn't. When I asked him to tell me=20 >>>>>>>>>>>> how he knows the link is up he said: I can ping the AP! Of=20 >>>>>>>>>>>> course after another >>>>>>>>>>>> 5 minutes of trying to convince him that pinging the AP=20 >>>>>>>>>>>> doesn't mean the radio is actually working he sent someone=20 >>>>>>>>>>>> to the hotel who in turn realised that the radio was not worki= ng. >>>>>>>>>>>> For those people who want rules to be transferred from the=20 >>>>>>>>>>>> HA to the MN, please think of your HA as this help desk=20 >>>>>>>>>>>> person, i.e. >>>>>>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>>>>>=20 >>>>>>>>>>>> I hope this helps with the realisation that decisions can't=20 >>>>>>>>>>>> be made here based on voting and that there is little merit=20 >>>>>>>>>>>> to transferring rules from the HA to the MN. Policies can=20 >>>>>>>>>>>> be transferred without any problems, but not rules. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From yuri.ismailov@ericsson.com Mon Jun 8 07:12:06 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 765C43A6C7D for ; Mon, 8 Jun 2009 07:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.073 X-Spam-Level: X-Spam-Status: No, score=-8.073 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 TFqUwL8LM-KG for ; Mon, 8 Jun 2009 07:12:03 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 3C3B33A6CEF for ; Mon, 8 Jun 2009 07:12:01 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9cae00000140d-6d-4a2d1c358fcc Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id E9.39.05133.53C1D2A4; Mon, 8 Jun 2009 16:12:05 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jun 2009 16:12:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Jun 2009 16:12:04 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+A= References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 08 Jun 2009 14:12:04.0700 (UTC) FILETIME=[199DE1C0:01C9E843] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 14:12:06 -0000 =20 =3D> Yes but I still think you're talking about something else. The = interface you're talking about seems to be associated with the HoA. This = is the only case where I can see the relevance of HA hints (not rules). = The interfaces I'm talking about and discussed in the context of flow = bindings are those associated with CoAs. There is nothing coming from = the HA about its links ...etc that can have any impact on CoA selection. Hesham here I tend to agree. I actually ment interfaces with CoA, but now = realized that in such configuration, where each of interfaces has it's = own HA configured, it is most likely that each of interfaces will have = different HoA. Once this is the case then moving a flow between those = interfaces will lead to change of HoA. As we are in MIP context, I would = better avoid that. In the whole discussion I mean interafces with CoA = because selection of HoA and/or associated to it interface can not be = based on physical characteristics of that interface. So the valid and meaningful scenario is moving flow(s) between = interfaces associated with the same HA, whether all interfaces of the MN = or some of them will be configured this way does not really matter. Fine with me. Should we finalize then? As I see it, once there is a = meaningful information, which can be sent in HA -> MN direction, then MN = can use it for re-evaluting policies and producing the new set of rules. = Definetely not at all times new rules will be produced, they may stay = unchanged, as it will be the case with many other events taking place at = either side: MN or HA. Is that correct? Regards Yuri -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Monday, June 08, 2009 2:00 PM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings Yuri,=20 I think we're getting close here. On 8/06/09 6:29 PM, "Yuri Ismailov" wrote: > Hesham, It looks like that the only point of disagreement is about=20 > changing HA and mapping between HA and access. > Some explanations of what I mean below: >=20 >=20 > 1. Changing HA. > As it follows from group charter change of HA is in the plans of MEXT=20 > WG. I assume that this is going to be a separate work item because the = > reason specified for that is very specific and relates to deployment=20 > more than to flow mobility. Do not want to speculate, about this right = > now but the change of HA does not necessarily means change of rules. > So the proposal is to not to discuss change of HA as you suggested. =3D> Agreed. >=20 > 2. In my example I do not mean change of HA as an explicit procedure=20 > specified separately. One confirmation to that is that single HA for=20 > all interfaces is included and valid option. Based on the HA -> MN=20 > exchange, the MN may perform interface selection procedure and may=20 > choose another interface for some flow(s). In multiple HA case it will = > result of the rules update MN -> HA to the HA which is relevant for=20 > the new interface chosen for flows. Please notice, There is nothing = about HA change, only about interface selection. =3D> Yes but I still think you're talking about something else. The = interface you're talking about seems to be associated with the HoA. This = is the only case where I can see the relevance of HA hints (not rules). = The interfaces I'm talking about and discussed in the context of flow = bindings are those associated with CoAs. There is nothing coming from = the HA about its links ...etc that can have any impact on CoA selection. >=20 > 3. I do not map HA and access. It is allowed for any access provider=20 > to offer HA service and once this is the case it will be so. Thus an=20 > MN can have multiple HA configured for the use on different = interfaces. =3D> Good, we agree on that too. Hesham >=20 > Regards > Yuri >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Friday, June 05, 2009 4:18 PM > To: Yuri Ismailov; Nicolas Montavont;=20 > pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of=20 > flowbindings >=20 >=20 >=20 >> First is that I assume that we have simulteneous multiaccess in mind, = >> i.e. MN has more than one interface to choose from for its flows. If=20 >> this is not the case then I will stop the discussion. This assumption = >> is based on the fact that we are (I hope at least) discussing flow = mobility. >=20 > =3D> Sure. >=20 >>=20 >> Secondly, I consider that MN chooses an interface but not CoA. I gave = >> a though about that and did not come up with any information which=20 >> can be derived from CoA in order to choose it. An interface has at=20 >> least expected characteristics, thus can be a subject of choice. Any=20 >> clarification about that would be appreciated. > =3D> An application would choose an interface, but of course the IP=20 > stack selects the corresponding address. I'm sure there is no = disagreement there. >=20 >>=20 >> Next assumptions are about possible configurations of HA >> - Single HA for all interfaces configured in the mobile. HA can=20 >> belong to any of the access providers of each of access technology = used by MN. >=20 > =3D> Ok. >=20 >>=20 >> - One HA per access or set of accesses, which is subset of all access = >> techologies presented or potentially may be presented (detached >> devices) in MN. >=20 > =3D> Now you're getting into a different problem space from flow = mobility. > This is why I wanted you to break the scenario down. We are not=20 > dealing with multiple HoAs in this work item, we're dealing with=20 > multiple CoAs, i.e. One HoA. >=20 >> Anticipating numerous questions about that can say that I looked at=20 >> such configuration and did not find anything strange with it, i.e.=20 >> (1) it works, >> (2) it does not require any change to MIP or any other of its=20 >> extensions. (3) Configuration is performed per interface and does not = >> introduce any ambiguities. (4) it is natural for access provider to=20 >> offer HA service. >=20 > =3D> Yes of course it works but as I read this I'm guessing that you=20 > want the MN to change HoA. This is not the problem we're discussing in = this WG. > Another issue, I'm not comfortable with the wording of "HA per access" > because they're not tied to access. Let's just say there are multiple=20 > Has and not associate it with an access. >=20 >>=20 >> - "Residential" HA. Assumption is that it can be either one of HA's=20 >> or a single HA for all types of accesses. This is the matter of MN=20 >> configuration. >> "Residential". >=20 > =3D> Please don't tie HA to access. >=20 >>=20 >> - Any HA may have multiple interfaces, e.g. "residential" HA may be=20 >> connected to mobile broadband, DSL, etc. >=20 > =3D> sure >=20 >>=20 >> Next assumption comes from the example (e.g. latest one) >> - Traffic shaping is applied in both directions (up/down) link (in=20 >> practice this is the case). >> - Traffic shaping (TS) is applied to user subscription. In other=20 >> words TS is applied to packets belonging to a particular subscription = >> but not to an aggregated traffic on gateway interfaces. HA is not=20 >> necessary (however, nothing prevents from that) a gateway where TS is = >> applied. >>=20 >>=20 >> I hope that I have not missed something, although it may be possible. >> If we can agree on that or correct if something is wrong here and=20 >> agree later then we know how to proceed further on >=20 > =3D> Your scenario is fine (with the wording changes for tying Has to = access). > But I want to pre-empt any suggestion that the HA will tell the MN to=20 > use a different HoA. This is very possible but it's not the problem=20 > being discussed here. It may well be something for charter discussion=20 > but it has zero impact on flow bindings for multiple CoAs. >=20 > Hesham >=20 >>=20 >> /yuri >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Friday, June 05, 2009 11:37 AM >> To: Yuri Ismailov; Nicolas Montavont;=20 >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of=20 >> flowbindings >>=20 >> Yuri, >>=20 >>=20 >>> Still not clear for me why you call scenarious invalid? >>> Some broadband providers (this is used in practice) have quota on=20 >>> the amount of traffic sent by users. Once quota is exceeded provider = >>> downgardes outgoing traffic from its network to 64Kbs (this figure=20 >>> is the real example from real provider). Such combination of to=20 >>> paths, where one is high speed, lets say 10 Mbs and another one is=20 >>> 64Kbs is quite crusual to apps running on top of TCP. >>> Not for all types of traffic though. >>=20 >> =3D> Yes I know the scenario but I keep saying to you that the change = >> in upstream routing in the HA has nothing to do with CoA selection by = >> the MN in the visited network. If anything, you want the MN to change = >> it's HoA depending on how the switch to another upstream ISP works.=20 >> It's a completely irrelevant issue to this discussion. Do you agree?=20 >> If not why not? I really want to see an answer to this point. >>=20 >> =20 >>=20 >>=20 >>>=20 >>> MN can not know about this situation. Nobody will send this=20 >>> information to MN. >>=20 >> =3D> Yes and if it knows what will it do??? If you can answer that = you=20 >> will fix the deadlock we have. >>=20 >>> That means that MN will choose its interfaces based on its knowledge = >>> about 10Mbs link capabilities. >>=20 >> =3D> You're talking about two different things. The MN doesn't choose = >> the HA's outgoing interface! What am I missing? >>=20 >> Obtaining this isnformation from HA is quite >>> significant to make a better decision about choice of interfaces for = >>> its flows. >>> This is concrete example of what happens in the reality. >>> Do you consider that this information will be useless for MN? >>=20 >> =3D> Completely useless. Unless I'm missing something in your = scenario. >> Just write down step by step what will happen and include messages. I = >> don't see how this can possibly be relevant to the MN. >>=20 >> Hesham >>=20 >> Hesham >>=20 >>>=20 >>> /yuri >>>=20 >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Thursday, June 04, 2009 4:38 PM >>> To: Yuri Ismailov; Nicolas Montavont;=20 >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>> flowbindings >>>=20 >>> Yuri, >>>=20 >>>=20 >>> On 5/06/09 12:01 AM, "Yuri Ismailov" = wrote: >>>=20 >>>> Hesham, >>>>=20 >>>> I provided several scenarious which you said are invalid. This is=20 >>>> where my conclusion about standpoint comes from. >>>> Whether you call hints policies or rules it does not change what=20 >>>> information can be provided by HA to MN. >>>=20 >>> =3D> It changes the outcome for the work item we're discussing. I'm=20 >>> trying to come to a conclusion on this and there is a huge=20 >>> difference between transferring policies and installing flow = bindings. >>>=20 >>>> By sending rules HA does not install anything in MN. Likewise, MN=20 >>>> does not install rules in HA, it informs HA about currently made = choices. >>>> As I remember rules will not be valid until proper Ack arrival,=20 >>>> which for me means that may not be instantiated at all. >>>> Niether rules nor polices are specific to MIP. As I wrote those can = >>>> be exchanged between hosts without any MIP implementation, just for = >>>> access selection purposes. Once it was decided to make it as part=20 >>>> of MIP protocol, I'm fine with that. Do not have any idea to=20 >>>> discuss this, while personally consider that the work on rules=20 >>>> transfer can very well fit into the MEXT group but as a separate=20 >>>> work item, but this is not the case now, so good enough the way it = is. >>>> And back again, it really gets repeated, so will lead to nowhere,=20 >>>> you've got my arguments and tell that the information, which I'm=20 >>>> talking about, is not usefull. What can I say more? I can put you=20 >>>> on my position and start asking questions instead of answering. So, = >>>> why it is not usefull? >>>=20 >>> =3D> I explained why the specific information you mentioned was not=20 >>> useful/useable by the MN and this is what I referred to as = unanswered. >>> Because if you agree with my previous explanations then we don't=20 >>> need to discuss it further. If you disagree you certainly didn't=20 >>> tell me why. You have the charge of proof because you want to change = >>> the way MIP works currently, that's all I'm trying to say. >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> /yuri >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Thursday, June 04, 2009 4:00 AM >>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>>> flowbindings >>>>=20 >>>> Yuri, >>>>=20 >>>>=20 >>>>=20 >>>>> Missing is additional information which may be helpful in making=20 >>>>> better decision about interface selection by MN. >>>>> Which information is that I wrote in my previous emails. Back to=20 >>>>> my examples (not all, do not want to repeat myself). If HA will=20 >>>>> have changed traffic shaping parameters on one of the incoming or=20 >>>>> outgoing interfaces, this will be important information for MN to = know. >>>>> We have agreed already that whether this information important or=20 >>>>> not, benfitial or not is a matter of standpoint. >>>>=20 >>>> =3D> I don't agree or like to think that it's a matter of = standpoint. >>>> That's why I asked you on every point you raised and compared this=20 >>>> to the MN's knowledge on e2e basis. Once we have "standpoints" then = >>>> we're getting outside the technical realm. The reason I don't think = >>>> it's useful is that this information cannot be used by the MN to=20 >>>> select a CoA. I've already stated that before and you seemed to=20 >>>> agree so I don't know why you repeat this as a reason for the HA to = >>>> install filters in the MN. Let me say it >>>> again: There is no correlation between the routing on the HA's=20 >>>> upstream interfaces/ISP with the MN's selection of a CoA. >>>>=20 >>>>> I consider that knowing more is a benefit and will help to get=20 >>>>> better result. >>>>>=20 >>>>> My point is still the same. I see the reverse rules sending as=20 >>>>> possibility to provide more information to the MN, thus make MN to = >>>>> get to better decision about interface selection for its flows. >>>>> This point has not changed since the beginning of the discussion. >>>>=20 >>>> =3D> This is why we're not making progress IMO: >>>>=20 >>>> 1. The hints you refer to are not the same things as installing=20 >>>> rules on the MN. Completely different information in fact. You've=20 >>>> essentially proved that when you suggested that the MN can accept=20 >>>> or reject them. So, let's not call them rules. The more direct word = >>>> for what you want to send is policies >>>>=20 >>>> 2. You didn't provide a valid scenario that we can discuss as to=20 >>>> why it's needed or how it could work. I've asked numerous questions = >>>> in each email that were not answered (with the exception of the=20 >>>> last email). It's not possible to progress the discussion without=20 >>>> answering each others' >>>> questions. You can go back through the threads and verify this. >>>>=20 >>>> 3. If we're sending rules from the HA to the MN and the MN can=20 >>>> reject those rules then the whole exercise is pointless. You really = >>>> want to send policies not rules. I can imagine those policies being = >>>> one of the inputs that the MN uses to make a decision. I still fail = >>>> to see how anything happening on the HA's upstream interfaces/ISP=20 >>>> link can possibly influence the MN's decision for CoA selection. >>>> This is another unanswered question. >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> /yuri >>>>>=20 >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: Wednesday, June 03, 2009 4:09 PM >>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>> pierrick.seite@orange-ftgroup.com >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of = >>>>> flowbindings >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 3/06/09 10:47 PM, "Yuri Ismailov" = wrote: >>>>>=20 >>>>>> Ok, see your point, however:-) >>>>>>=20 >>>>>> The major difference here is that your are talking about CoA=20 >>>>>> selection and I'm talking about interface selection. Quite a big=20 >>>>>> difference. >>>>>=20 >>>>> =3D> No, that's not the point really. The point is that there is = no=20 >>>>> relationship between CoA/interface selection on the MN and the=20 >>>>> upstream ISP for the home network. >>>>>=20 >>>>>> I do not see any grounds for MN to select CoA, based on what? >>>>>> Prefix length? >>>>>> While selection of an interface is based on expected=20 >>>>>> characteristics of the communication. Routes (up/down)link in my=20 >>>>>> opinion do have impact on the characteristics and this is exactly = >>>>>> the information missing in the MN when selecting interface. >>>>>=20 >>>>> =3D> There is nothing missing for the MN to make this selection. >>>>> Please tell us specifically what is missing. You're changing=20 >>>>> points on me all the time now. >>>>> Lets stick to one point at a time. What's missing? >>>>>=20 >>>>>>=20 >>>>>> Whenever, MN decides to move a flow, the reason can be anything=20 >>>>>> but not which CoA it has configured on each interface. >>>>>>=20 >>>>>> Another thing is that MN will notice something e2e if and only if = >>>>>> such support is implemented in the MN. >>>>>=20 >>>>> =3D> Of course, so what? >>>>>=20 >>>>> Moreover, this notice can not be made at IP layer. >>>>>> TCP fights alone with all problems and never tells to any other=20 >>>>>> layer what is going on. So what is left? Two options. Add this=20 >>>>>> support to operating system, which makes its (support) existence=20 >>>>>> questionable, or to applications, which is even more = questionable. >>>>>=20 >>>>> =3D> It's interesting that you think it's questionable to add the=20 >>>>> support to the MN's OS but not questionable to add the support to=20 >>>>> the HA's OS, which will not lead to the same reliability as if it=20 >>>>> were done in the MN. It doesn't make sense to me. >>>>>=20 >>>>>>=20 >>>>>>>>=20 >>>>>>>> Well, that's debatable, but this is clearly not a reason to do=20 >>>>>>>> anything. >>>>>>>>=20 >>>>>> Are you serious about that MIP may be broken because of that? >>>>>=20 >>>>> =3D> Yes! It's not designed to do what you want to do. Luckily, in = >>>>> this case what you want, IMO, is broken anyway so it's not a = problem. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>>=20 >>>>>> /yuri >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>> Sent: Wednesday, June 03, 2009 1:15 PM >>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>> pierrick.seite@orange-ftgroup.com >>>>>> Cc: mext@ietf.org >>>>>> Subject: Re: [MEXT] Important considerations for directionality=20 >>>>>> of flowbindings >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Still some answers, despite knowing that in your opinion they=20 >>>>>>> are not benefits. >>>>>>>=20 >>>>>>> First of all MIP will not be breaked if the rules will be sent=20 >>>>>>> in both directions. >>>>>>=20 >>>>>> =3D> Well, that's debatable, but this is clearly not a reason to = do=20 >>>>>> anything. >>>>>>=20 >>>>>>>=20 >>>>>>> - Access provider preferences relate to the use of backbone=20 >>>>>>> provider, which may vary with the time of day. Changing backbone = >>>>>>> provider can make quite big difference for commnication between=20 >>>>>>> HA (if HA service is provided by the same access provider) and = CN(s). >>>>>>> The difference can be expressed in, let's say, number of hops,=20 >>>>>>> load, possibly something else. Such change is an event and may=20 >>>>>>> have an impact on the overall communication. This can be told=20 >>>>>>> directly to MN or HA. Direct communication to MN (if accepted as >>>>>>> benefit:-)) in such case will need standardization.=20 >>>>>>> Communication of this information to HA does not (I consider = this as a benefit). >>>>>>> HA may act upon that event, and the rest you >>>>>>> know: rules in reverse direction. >>>>>>=20 >>>>>> =3D> There is no need to _tell_ the MN anything. There are two = issues here. >>>>>> First, changing network conditions are best known e2e. So the MN=20 >>>>>> will know that anyway based on the traffic running between it and = the CN. >>>>>> The other issue is related to cost for certain times of day. This = >>>>>> is a routing issue in the HA and has nothing to do with which=20 >>>>>> interface the MN selects. The selected CoA has zero impact on the = >>>>>> HA's upstream selection. Completely irrelevant actually. >>>>>> Of course, as far as cost on the visited link, the MN knows best. >>>>>>=20 >>>>>>>=20 >>>>>>> - Access provider may set up different parameters for traffic=20 >>>>>>> shaping for each of HA interfaces. These preferences may vary=20 >>>>>>> independently of change of backbone provider but dependently on=20 >>>>>>> the time of day. >>>>>>> The rest you know, whether it changes somebodies opinion. >>>>>>=20 >>>>>> =3D> But again, this has zero effect on CoA selection. The two=20 >>>>>> issues are completely orthogonal. Selecting CoA1 or CoA2 has zero = >>>>>> impact on the HA's upstream route. >>>>>>=20 >>>>>>>=20 >>>>>>> - I presume that in RO mode this is similar to HA mode, and I'm=20 >>>>>>> in when it comes to send rules in reverse direction between CN = and MN. >>>>>>> Benefits of doing that is that any change percieved by CN as=20 >>>>>>> important to react upon can be expressed in proposal of new = rules. >>>>>>> The sources causing changes may include but not limited to, are=20 >>>>>>> user, network managemnt events, application generated events, = etc. >>>>>>>=20 >>>>>>> So feel free to consider this as benefits or not >>>>>>=20 >>>>>> =3D> You seem to think that there is a relationship between=20 >>>>>> upstream routing and CoA selection. That's not the case at all.=20 >>>>>> These are two different addresses from two different networks. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>>=20 >>>>>>> /yuri >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>> Sent: Wednesday, June 03, 2009 11:47 AM >>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>> Cc: mext@ietf.org >>>>>>> Subject: Re: [MEXT] Important considerations for directionality=20 >>>>>>> of flowbindings >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 3/06/09 7:33 PM, "Yuri Ismailov" = wrote: >>>>>>>=20 >>>>>>>> Hesham, >>>>>>>>=20 >>>>>>>> Whenever we talk about sending additional information, the=20 >>>>>>>> "waste of bandwidth" can be brought up. So I do not have an=20 >>>>>>>> answer for that besides speculations around it. >>>>>>>=20 >>>>>>> =3D> no no, I don't mean it literally, I mean that the message=20 >>>>>>> doesn't do anything, i.e. Has no benefit. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Speaking about benefits, everybody who knows the area is=20 >>>>>>>> capable of turning things up side down. I assume it is=20 >>>>>>>> subjective standpoint of considering things as benefits or=20 >>>>>>>> disadvantages and all is about to agree or disagree. >>>>>>>=20 >>>>>>> =3D> That's fine, I'm asking for benefits in your opinion not=20 >>>>>>> someone else's. >>>>>>> It's impossible to discuss this if I can't see any benefits=20 >>>>>>> because you didn't send any. What you sent were actions that can = >>>>>>> be done by the HA and I responded by saying that the same (or >>>>>>> more) information is available to the MN. Therefore, if you=20 >>>>>>> think there are additional benefits to doing this in the HA then = >>>>>>> you need to tell us. >>>>>>>=20 >>>>>>> The bottom line is this: MIP works by letting the MN install=20 >>>>>>> bindings in the HA. If you want things to work in reverse you=20 >>>>>>> need to justify it. I can't see any justifications because=20 >>>>>>> you're not answering my questions on your scenarios. So, count=20 >>>>>>> me out on the reverse direction :). >>>>>>>=20 >>>>>>>=20 >>>>>>> For >>>>>>>> me those I wrote about are benefits or potential benefits if = you want. >>>>>>>=20 >>>>>>> =3D> No you didn't. You wrote about things that can be done. = Many=20 >>>>>>> things can be done by many entities, the question is why the HA=20 >>>>>>> and not the MN. >>>>>>>=20 >>>>>>>> One important thing in the discussion, although mentioned, but=20 >>>>>>>> forgotten later is that by making rules distribution one way=20 >>>>>>>> only, we do create limitation for benefits, or potential=20 >>>>>>>> benefits if this sounds better. >>>>>>>=20 >>>>>>> =3D> Well, we won't know what we're missing unless someone tells = us. >>>>>>> So far no one has mentioned the advantages of doing things in=20 >>>>>>> the reverse direction. >>>>>>> There is always something missing from a protocol (it's=20 >>>>>>> engineering), the question us whether it's significant or worth=20 >>>>>>> the trouble. >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>>=20 >>>>>>>> /yuri >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>> Sent: Wednesday, June 03, 2009 10:10 AM >>>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>> Cc: mext@ietf.org >>>>>>>> Subject: Re: [MEXT] Important considerations for directionality = >>>>>>>> of flowbindings >>>>>>>>=20 >>>>>>>> Yuri, >>>>>>>>=20 >>>>>>>> I can't parse those events you refer to. I'l answer both emails = here. >>>>>>>> First the events you refer to: >>>>>>>>=20 >>>>>>>>>> - network condition towards CN(s) >>>>>>>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>>>>>>=20 >>>>>>>> =3D> What's the event? A change in those conditions? The MN = knows=20 >>>>>>>> the conditions of the e2e path as well as or better than the = HA. >>>>>>>> What is the benefit of having the HA send a hint and how=20 >>>>>>>> reliable is that hint anyway? >>>>>>>>=20 >>>>>>>>>> - Access provider (any access, not necessarily wireless) who=20 >>>>>>>>>> offeres HA services preferences change >>>>>>>>=20 >>>>>>>> =3D> Preferences change to what?? How does it know if such = change=20 >>>>>>>> works for the MN at all? This is way too vague to be able to=20 >>>>>>>> discuss tradeoffs. >>>>>>>>=20 >>>>>>>>>> - Change of the access provider traffic to another backbone=20 >>>>>>>>>> provider due to the time of the day. >>>>>>>>>> - Traffic condition on HA interface, which accepts traffic=20 >>>>>>>>>> from MN if MN sends on some particular local interface >>>>>>>>=20 >>>>>>>> =3D> These are path changes. The HA has _no idea_ how such a=20 >>>>>>>> change affects each MN/CN combination and it's "hint" can cause = >>>>>>>> more problems than it solves. BTW, if you're talking about=20 >>>>>>>> hints then we're no longer talking about installing bindings in = >>>>>>>> the MN. This is a different topic. MIP doesn't transfer hints,=20 >>>>>>>> it pretty much sends "orders" >>>>>>>> from one end to another. >>>>>>>>=20 >>>>>>>> Now to the actions required by the MN: >>>>>>>>=20 >>>>>>>>> - reject, >>>>>>>>> - re-evaluate and reject >>>>>>>>> - re-evaluate and accept >>>>>>>>> - accept >>>>>>>>=20 >>>>>>>> =3D> First, by assuming that the MN can reject the "hint" as = you=20 >>>>>>>> call it you invalidate the whole argument for the HA to install = rules. >>>>>>>> Rejecting a hint or even evaluating it means that the MN knows = more. >>>>>>>> Therefore, the HA's hint is a complete waste of bandwidth. >>>>>>>>=20 >>>>>>>> I'm still confused about the _benefits_ you see here. Or are=20 >>>>>>>> you assuming that the MN can't know those hints without the=20 >>>>>>>> HA's involvement? But if you're assuming that, then how can it=20 >>>>>>>> reject the hints? This whole proposal makes no sense to me at=20 >>>>>>>> all. Not to mention the complexity you implicitly assume in=20 >>>>>>>> order to generate those, hopefully reliable, hints. >>>>>>>>=20 >>>>>>>> Hesham >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 3/06/09 5:23 PM, "Yuri Ismailov" = wrote: >>>>>>>>=20 >>>>>>>>> Hesham, >>>>>>>>>=20 >>>>>>>>> In my view these are events not scenarious. These events are=20 >>>>>>>>> known by HA but not MN. If HA acts upon events, given that it=20 >>>>>>>>> knows somewhat more about MN, not only IP addresses, it (HA)=20 >>>>>>>>> can generate new rules and send them as hint to MN. Back=20 >>>>>>>>> again, MN has four >>>>>>>>> options: >>>>>>>>>=20 >>>>>>>>> The benefit will be obviously that the new rules (if accepted) = >>>>>>>>> may llead to a better overall communication characteristics. >>>>>>>>>=20 >>>>>>>>> /yuri >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> =3D> I'm trying to understand what you mean above. These are = all=20 >>>>>>>>> scenarios, the question is: What is the benefit for the HA to=20 >>>>>>>>> transfer rules? The HA will not know the path between the MN=20 >>>>>>>>> and CN more than either node does. So I don't understand what=20 >>>>>>>>> _benefits_ you see here. >>>>>>>>>=20 >>>>>>>>> Hesham >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Pretty much sure that there are more examples and I encourage = >>>>>>>>>> to think about those not from MN point of view but rather=20 >>>>>>>>>> from the HA service provider. >>>>>>>>>>=20 >>>>>>>>>> /yuri >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>>> Cc: mext@ietf.org >>>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>>> directionality of flowbindings >>>>>>>>>>=20 >>>>>>>>>> Yuri, >>>>>>>>>>=20 >>>>>>>>>> It is just rules TRANSFER which is the matter of MIP. So=20 >>>>>>>>>> where >>>>>>>>>>> is the logic when saying that MN to HA rules transfer is a=20 >>>>>>>>>>> practical engineering and HA to MN is an academic interest? >>>>>>>>>>=20 >>>>>>>>>> =3D> I think we've (I'm including myself) highlighted several = >>>>>>>>>> reasons for why it makes little sense to transfer rules from=20 >>>>>>>>>> HA to MN. >>>>>>>>>> Instead of rat-holing on theory Vs practice, you (or others=20 >>>>>>>>>> advocating the other direction) need to come up with reasons=20 >>>>>>>>>> for doing things this way. This way we can think like=20 >>>>>>>>>> engineers about tradeoffs. >>>>>>>>>> Absent that, I don't see any point in having theory Vs=20 >>>>>>>>>> practice high level discussions, which will lead nowhere. >>>>>>>>>>=20 >>>>>>>>>> Hesham >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Regards >>>>>>>>>>> Yuri >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>>>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>>>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>>>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>>>> directionality of flowbindings >>>>>>>>>>>=20 >>>>>>>>>>> Hi Pierrick, >>>>>>>>>>>=20 >>>>>>>>>>> On Jun 2, 2009, at 4:11 PM, >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>> Please see inline comment. >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>> Pierrick >>>>>>>>>>>>=20 >>>>>>>>>>>> ________________________________________ >>>>>>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>>> De la part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 = 09:35 =C0 : >>>>>>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important=20 >>>>>>>>>>>> considerations for directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham, >>>>>>>>>>>> This is nice story and makes some sense for the discssion,=20 >>>>>>>>>>>> however some details are ommited. In your adventure with=20 >>>>>>>>>>>> the helpdesk, it (the >>>>>>>>>>>> helpdesk) is a third party service and thus your=20 >>>>>>>>>>>> conclusions make sence. >>>>>>>>>>>> Think of the situation when superior of a heldesk person=20 >>>>>>>>>>>> will tell him/her to check access point in some room. Would = >>>>>>>>>>>> it be the same reaction? I assume not. By that I mean that=20 >>>>>>>>>>>> if, for example, I'll install home agent in my home=20 >>>>>>>>>>>> network, I can make it know anything I want about MN, and=20 >>>>>>>>>>>> more intresting is that how I will do it, does not require=20 >>>>>>>>>>>> any standardization. >>>>>>>>>>>> In other words, I'm superior of my HA. >>>>>>>>>>>> This situation is not unthinkable, I personally believe=20 >>>>>>>>>>>> that this is much more efficient way of using HA=20 >>>>>>>>>>>> fnctionality as opposed to big service providers who will=20 >>>>>>>>>>>> have to fight with scalability and performance. >>>>>>>>>>>> However, one does not exclude another. >>>>>>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> The difference between policy and rules is not only a=20 >>>>>>>>>>>> matter of conversion. A policy, is a static, or=20 >>>>>>>>>>>> quasi-static, set of guidance for the MN (e.g use access=20 >>>>>>>>>>>> network X for application type >>>>>>>>>>>> A,...) while a rule update requires to be more dynamic. I = mean: >>>>>>>>>>>> eventually a policy could be updated depending on network=20 >>>>>>>>>>>> condition (e.g if X overloaded, use access network Y for=20 >>>>>>>>>>>> application type A,...) but a rule reacts on local triggers = (e.g. >>>>>>>>>>>> modification of the radio link >>>>>>>>>>>> quality) with a shorter period of variation. So, IMHO,=20 >>>>>>>>>>>> there is no requirement for updating policy on a short=20 >>>>>>>>>>>> period and out-of-band mechanism can be used (e.g. IEEE=20 >>>>>>>>>>>> 802.21 in push mode,...). >>>>>>>>>>>=20 >>>>>>>>>>> Fully agree! >>>>>>>>>>> This is why I do not support the exchange of rules from the=20 >>>>>>>>>>> HA to the MN. >>>>>>>>>>> Policies may be exchanged from the HA to the MN, but MIP is=20 >>>>>>>>>>> definitely not the protocol to transport them. >>>>>>>>>>>=20 >>>>>>>>>>> Nicolas >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> My 2 cents... >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Is there any reason to restrict where such convertion takes = place? >>>>>>>>>>>> True >>>>>>>>>>>> that a HA does not know what is going on in the access=20 >>>>>>>>>>>> network, on the other hand HA may know what is the network=20 >>>>>>>>>>>> condition between HA and correspondent node. Either of this = >>>>>>>>>>>> information is important, if not equally important. >>>>>>>>>>>> It is not really difficult to let an MN to reject rules=20 >>>>>>>>>>>> sent by HA, which in my view would be quite natural. This=20 >>>>>>>>>>>> implies that HA must follow the rules installed by MN until = >>>>>>>>>>>> explicit acceptance has been received from MN. >>>>>>>>>>>> Such procedure is very similar to an MN beahviour when=20 >>>>>>>>>>>> initiating new BU, where MN is not supposed to send any=20 >>>>>>>>>>>> traffic before BU confirmation. >>>>>>>>>>>> BTW, what is the numerical representation of "rough = consensus"? >>>>>>>>>>>> I assume is when majority is for, is it so? >>>>>>>>>>>> Yuri >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>>> On Behalf Of Hesham Soliman >>>>>>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>>>>>> To: mext >>>>>>>>>>>> Subject: [MEXT] Important considerations for directionality = >>>>>>>>>>>> of flow bindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>> I've always been a fan of the IETF's tradition of rough=20 >>>>>>>>>>>> concensus (as opposed to voting). To me, this implies that=20 >>>>>>>>>>>> you need to get your point across and get other people to=20 >>>>>>>>>>>> see that point of view. >>>>>>>>>>>> As opposed to other organisations that require their=20 >>>>>>>>>>>> members to vote and end up with rigid political positions. >>>>>>>>>>>>=20 >>>>>>>>>>>> The chairs asked us about the directionality question of=20 >>>>>>>>>>>> the flows bindings. >>>>>>>>>>>> On the charter question, I said that the charter doesn't=20 >>>>>>>>>>>> need to mention how a solution should work, but rather what = >>>>>>>>>>>> problem needs to be solved. >>>>>>>>>>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>>>>>>>>>> transferring rules "between" the MN and HA without=20 >>>>>>>>>>>> mentioning directions. >>>>>>>>>>>>=20 >>>>>>>>>>>> Nevertheless, we still need to agree on identifying the=20 >>>>>>>>>>>> requirement for the solution. And when it comes to this,=20 >>>>>>>>>>>> I'm strongly against voting and I'll practice this by=20 >>>>>>>>>>>> explaining in this email why I think rules can not be=20 >>>>>>>>>>>> transferred from the HA to the MN and that the only=20 >>>>>>>>>>>> direction that makes sense in MIP is >>>>>>>>>>>> MN->HA. I'll deliberately ignore arguments like "some=20 >>>>>>>>>>>> MN->people want >>>>>>>>>>>> this" or "an SDO wants this". They fall under the=20 >>>>>>>>>>>> "meaningless words" >>>>>>>>>>>> category and I'm incapable of discussing them because they=20 >>>>>>>>>>>> come with voting attitudes. They all need to be justified=20 >>>>>>>>>>>> if the WG wants to have a technical _discussion_. >>>>>>>>>>>>=20 >>>>>>>>>>>> Here are my reasons: >>>>>>>>>>>>=20 >>>>>>>>>>>> 1. The HA does not know whether a CoA is tied to a certain=20 >>>>>>>>>>>> access technology. It is one thing for the HA to send a=20 >>>>>>>>>>>> message saying "forward port 80 traffic on a wifi link" (a >>>>>>>>>>>> policy) and a completely different thing to say "forward=20 >>>>>>>>>>>> port 80 traffic using CoA 3ffe::1" >>>>>>>>>>>> (a rule). >>>>>>>>>>>>=20 >>>>>>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem = now? >>>>>>>>>>>> The problem is that the HA has no idea about dynamic=20 >>>>>>>>>>>> changes on that wifi link. It doesn't know if it's=20 >>>>>>>>>>>> congested, it doesn't know what application is using port=20 >>>>>>>>>>>> 80 (it doesn't have to be web >>>>>>>>>>>> traffic) or port 8000 for that matter and doesn't even know = >>>>>>>>>>>> if the AP of that wifi link works at all. >>>>>>>>>>>> Finally, it >>>>>>>>>>>> doesn't know the user's policies or other admin policies=20 >>>>>>>>>>>> for that MN. >>>>>>>>>>>> This type of information needs to be sent regularly because = >>>>>>>>>>>> it changes all the time and requires serious cross layer=20 >>>>>>>>>>>> integration including sometimes layer 8 integration! It's=20 >>>>>>>>>>>> completely impractical. >>>>>>>>>>>>=20 >>>>>>>>>>>> 3. If the HA installed rules in the MN, what happens if the = >>>>>>>>>>>> MN wants to change those rules. Say the wifi link went=20 >>>>>>>>>>>> down, or the MN's wifi interface went down and it wants to=20 >>>>>>>>>>>> move that traffic to another interface. Would the HA reject = >>>>>>>>>>>> such move? >>>>>>>>>>>> Does the MN have to justify to the HA why it needs to move=20 >>>>>>>>>>>> traffic? Does that involve writing a letter perhaps? >>>>>>>>>>>> If you say "well in that case, the HA should let the MN=20 >>>>>>>>>>>> move the traffic" >>>>>>>>>>>> then I'll ask you: what's the point of having the HA=20 >>>>>>>>>>>> install this stuff if it has no authority and how does it=20 >>>>>>>>>>>> know the reason for the MN's movement of the flow? >>>>>>>>>>>> The way to control how users do things is to incentivise=20 >>>>>>>>>>>> them with charging models and show them that things work=20 >>>>>>>>>>>> better on certain technologies, not by installing rules=20 >>>>>>>>>>>> that can't be followed. It's a broken mindset and we've=20 >>>>>>>>>>>> known that it's broken for a long time. >>>>>>>>>>>>=20 >>>>>>>>>>>> 4. Some people mentioned that the HA should be able to=20 >>>>>>>>>>>> revoke flows on the MN. I'm perfectly fine with that, just=20 >>>>>>>>>>>> extend the binding revocation draft to handle flows and the = >>>>>>>>>>>> rest is pretty straight forward. >>>>>>>>>>>>=20 >>>>>>>>>>>> Finally, I'll indulge in a true story that happened to me a = >>>>>>>>>>>> few years ago when I found that my wifi link wasn't working = >>>>>>>>>>>> in a hotel (no >>>>>>>>>>>> radio) >>>>>>>>>>>> and called the help desk. He insisted that the link was up=20 >>>>>>>>>>>> an I insisted that it wasn't. When I asked him to tell me=20 >>>>>>>>>>>> how he knows the link is up he said: I can ping the AP! Of=20 >>>>>>>>>>>> course after another >>>>>>>>>>>> 5 minutes of trying to convince him that pinging the AP=20 >>>>>>>>>>>> doesn't mean the radio is actually working he sent someone=20 >>>>>>>>>>>> to the hotel who in turn realised that the radio was not = working. >>>>>>>>>>>> For those people who want rules to be transferred from the=20 >>>>>>>>>>>> HA to the MN, please think of your HA as this help desk=20 >>>>>>>>>>>> person, i.e. >>>>>>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>>>>>=20 >>>>>>>>>>>> I hope this helps with the realisation that decisions can't = >>>>>>>>>>>> be made here based on voting and that there is little merit = >>>>>>>>>>>> to transferring rules from the HA to the MN. Policies can=20 >>>>>>>>>>>> be transferred without any problems, but not rules. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From hesham@elevatemobile.com Mon Jun 8 07:29:45 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53A8628C11B for ; Mon, 8 Jun 2009 07:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 lfY4Y0qkNjJV for ; Mon, 8 Jun 2009 07:29:42 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 43EB83A6B5A for ; Mon, 8 Jun 2009 07:29:40 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MDfqr-0001gA-0J; Tue, 09 Jun 2009 00:29:34 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 09 Jun 2009 00:29:22 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 14:29:45 -0000 On 9/06/09 12:12 AM, "Yuri Ismailov" wrote: > =20 > =3D> Yes but I still think you're talking about something else. The interfa= ce > you're talking about seems to be associated with the HoA. This is the onl= y > case where I can see the relevance of HA hints (not rules). The interface= s I'm > talking about and discussed in the context of flow bindings are those > associated with CoAs. There is nothing coming from the HA about its links > ...etc that can have any impact on CoA selection. >=20 > Hesham > here I tend to agree. I actually ment interfaces with CoA, but now realiz= ed > that in such configuration, where each of interfaces has it's own HA > configured, it is most likely that each of interfaces will have different= HoA. > Once this is the case then moving a flow between those interfaces will le= ad to > change of HoA. As we are in MIP context, I would better avoid that. In th= e > whole discussion I mean interafces with CoA because selection of HoA and/= or > associated to it interface can not be based on physical characteristics o= f > that interface. =3D> Sounds fine to me. >=20 > So the valid and meaningful scenario is moving flow(s) between interfaces > associated with the same HA, whether all interfaces of the MN or some of = them > will be configured this way does not really matter. >=20 > Fine with me. Should we finalize then? As I see it, once there is a meani= ngful > information, which can be sent in HA -> MN direction, then MN can use it = for > re-evaluting policies and producing the new set of rules. Definetely not = at > all times new rules will be produced, they may stay unchanged, as it will= be > the case with many other events taking place at either side: MN or HA. >=20 > Is that correct? =3D> So now that we agree that we are only talking about CoAs then I don't se= e any meaningful information coming from the HA. Hints about upstream routing changes ...etc are relevant to HoA selection (even if the HoA is not tied t= o a physical interface it doesn't matter). This is an interesting problem to discuss but I want to be clear on its context. So to summarise my opinion: HA-> MN hints (not rules) may be relevant for intial HoA selection for certain connections. The types of hints and how to formulate this in a global manner can lead to interesting work (although it's a complex problem). However, this information is not in anyway relevant to CoA/physical interface selection on the MN. Hesham >=20 > Regards > Yuri >=20 >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Monday, June 08, 2009 2:00 PM > To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of > flowbindings >=20 > Yuri,=20 >=20 > I think we're getting close here. >=20 >=20 > On 8/06/09 6:29 PM, "Yuri Ismailov" wrote: >=20 >> Hesham, It looks like that the only point of disagreement is about >> changing HA and mapping between HA and access. >> Some explanations of what I mean below: >>=20 >>=20 >> 1. Changing HA. >> As it follows from group charter change of HA is in the plans of MEXT >> WG. I assume that this is going to be a separate work item because the >> reason specified for that is very specific and relates to deployment >> more than to flow mobility. Do not want to speculate, about this right >> now but the change of HA does not necessarily means change of rules. >> So the proposal is to not to discuss change of HA as you suggested. >=20 > =3D> Agreed. >=20 >>=20 >> 2. In my example I do not mean change of HA as an explicit procedure >> specified separately. One confirmation to that is that single HA for >> all interfaces is included and valid option. Based on the HA -> MN >> exchange, the MN may perform interface selection procedure and may >> choose another interface for some flow(s). In multiple HA case it will >> result of the rules update MN -> HA to the HA which is relevant for >> the new interface chosen for flows. Please notice, There is nothing abou= t HA >> change, only about interface selection. >=20 > =3D> Yes but I still think you're talking about something else. The interfa= ce > you're talking about seems to be associated with the HoA. This is the onl= y > case where I can see the relevance of HA hints (not rules). The interface= s I'm > talking about and discussed in the context of flow bindings are those > associated with CoAs. There is nothing coming from the HA about its links > ...etc that can have any impact on CoA selection. >=20 >>=20 >> 3. I do not map HA and access. It is allowed for any access provider >> to offer HA service and once this is the case it will be so. Thus an >> MN can have multiple HA configured for the use on different interfaces. >=20 > =3D> Good, we agree on that too. >=20 > Hesham >=20 >>=20 >> Regards >> Yuri >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Friday, June 05, 2009 4:18 PM >> To: Yuri Ismailov; Nicolas Montavont; >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of >> flowbindings >>=20 >>=20 >>=20 >>> First is that I assume that we have simulteneous multiaccess in mind, >>> i.e. MN has more than one interface to choose from for its flows. If >>> this is not the case then I will stop the discussion. This assumption >>> is based on the fact that we are (I hope at least) discussing flow mobi= lity. >>=20 >> =3D> Sure. >>=20 >>>=20 >>> Secondly, I consider that MN chooses an interface but not CoA. I gave >>> a though about that and did not come up with any information which >>> can be derived from CoA in order to choose it. An interface has at >>> least expected characteristics, thus can be a subject of choice. Any >>> clarification about that would be appreciated. >> =3D> An application would choose an interface, but of course the IP >> stack selects the corresponding address. I'm sure there is no disagreeme= nt >> there. >>=20 >>>=20 >>> Next assumptions are about possible configurations of HA >>> - Single HA for all interfaces configured in the mobile. HA can >>> belong to any of the access providers of each of access technology used= by >>> MN. >>=20 >> =3D> Ok. >>=20 >>>=20 >>> - One HA per access or set of accesses, which is subset of all access >>> techologies presented or potentially may be presented (detached >>> devices) in MN. >>=20 >> =3D> Now you're getting into a different problem space from flow mobility. >> This is why I wanted you to break the scenario down. We are not >> dealing with multiple HoAs in this work item, we're dealing with >> multiple CoAs, i.e. One HoA. >>=20 >>> Anticipating numerous questions about that can say that I looked at >>> such configuration and did not find anything strange with it, i.e. >>> (1) it works, >>> (2) it does not require any change to MIP or any other of its >>> extensions. (3) Configuration is performed per interface and does not >>> introduce any ambiguities. (4) it is natural for access provider to >>> offer HA service. >>=20 >> =3D> Yes of course it works but as I read this I'm guessing that you >> want the MN to change HoA. This is not the problem we're discussing in t= his >> WG. >> Another issue, I'm not comfortable with the wording of "HA per access" >> because they're not tied to access. Let's just say there are multiple >> Has and not associate it with an access. >>=20 >>>=20 >>> - "Residential" HA. Assumption is that it can be either one of HA's >>> or a single HA for all types of accesses. This is the matter of MN >>> configuration. >>> "Residential". >>=20 >> =3D> Please don't tie HA to access. >>=20 >>>=20 >>> - Any HA may have multiple interfaces, e.g. "residential" HA may be >>> connected to mobile broadband, DSL, etc. >>=20 >> =3D> sure >>=20 >>>=20 >>> Next assumption comes from the example (e.g. latest one) >>> - Traffic shaping is applied in both directions (up/down) link (in >>> practice this is the case). >>> - Traffic shaping (TS) is applied to user subscription. In other >>> words TS is applied to packets belonging to a particular subscription >>> but not to an aggregated traffic on gateway interfaces. HA is not >>> necessary (however, nothing prevents from that) a gateway where TS is >>> applied. >>>=20 >>>=20 >>> I hope that I have not missed something, although it may be possible. >>> If we can agree on that or correct if something is wrong here and >>> agree later then we know how to proceed further on >>=20 >> =3D> Your scenario is fine (with the wording changes for tying Has to acce= ss). >> But I want to pre-empt any suggestion that the HA will tell the MN to >> use a different HoA. This is very possible but it's not the problem >> being discussed here. It may well be something for charter discussion >> but it has zero impact on flow bindings for multiple CoAs. >>=20 >> Hesham >>=20 >>>=20 >>> /yuri >>>=20 >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Friday, June 05, 2009 11:37 AM >>> To: Yuri Ismailov; Nicolas Montavont; >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of >>> flowbindings >>>=20 >>> Yuri, >>>=20 >>>=20 >>>> Still not clear for me why you call scenarious invalid? >>>> Some broadband providers (this is used in practice) have quota on >>>> the amount of traffic sent by users. Once quota is exceeded provider >>>> downgardes outgoing traffic from its network to 64Kbs (this figure >>>> is the real example from real provider). Such combination of to >>>> paths, where one is high speed, lets say 10 Mbs and another one is >>>> 64Kbs is quite crusual to apps running on top of TCP. >>>> Not for all types of traffic though. >>>=20 >>> =3D> Yes I know the scenario but I keep saying to you that the change >>> in upstream routing in the HA has nothing to do with CoA selection by >>> the MN in the visited network. If anything, you want the MN to change >>> it's HoA depending on how the switch to another upstream ISP works. >>> It's a completely irrelevant issue to this discussion. Do you agree? >>> If not why not? I really want to see an answer to this point. >>>=20 >>> =20 >>>=20 >>>=20 >>>>=20 >>>> MN can not know about this situation. Nobody will send this >>>> information to MN. >>>=20 >>> =3D> Yes and if it knows what will it do??? If you can answer that you >>> will fix the deadlock we have. >>>=20 >>>> That means that MN will choose its interfaces based on its knowledge >>>> about 10Mbs link capabilities. >>>=20 >>> =3D> You're talking about two different things. The MN doesn't choose >>> the HA's outgoing interface! What am I missing? >>>=20 >>> Obtaining this isnformation from HA is quite >>>> significant to make a better decision about choice of interfaces for >>>> its flows. >>>> This is concrete example of what happens in the reality. >>>> Do you consider that this information will be useless for MN? >>>=20 >>> =3D> Completely useless. Unless I'm missing something in your scenario. >>> Just write down step by step what will happen and include messages. I >>> don't see how this can possibly be relevant to the MN. >>>=20 >>> Hesham >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> /yuri >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Thursday, June 04, 2009 4:38 PM >>>> To: Yuri Ismailov; Nicolas Montavont; >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of >>>> flowbindings >>>>=20 >>>> Yuri, >>>>=20 >>>>=20 >>>> On 5/06/09 12:01 AM, "Yuri Ismailov" wrot= e: >>>>=20 >>>>> Hesham, >>>>>=20 >>>>> I provided several scenarious which you said are invalid. This is >>>>> where my conclusion about standpoint comes from. >>>>> Whether you call hints policies or rules it does not change what >>>>> information can be provided by HA to MN. >>>>=20 >>>> =3D> It changes the outcome for the work item we're discussing. I'm >>>> trying to come to a conclusion on this and there is a huge >>>> difference between transferring policies and installing flow bindings. >>>>=20 >>>>> By sending rules HA does not install anything in MN. Likewise, MN >>>>> does not install rules in HA, it informs HA about currently made choi= ces. >>>>> As I remember rules will not be valid until proper Ack arrival, >>>>> which for me means that may not be instantiated at all. >>>>> Niether rules nor polices are specific to MIP. As I wrote those can >>>>> be exchanged between hosts without any MIP implementation, just for >>>>> access selection purposes. Once it was decided to make it as part >>>>> of MIP protocol, I'm fine with that. Do not have any idea to >>>>> discuss this, while personally consider that the work on rules >>>>> transfer can very well fit into the MEXT group but as a separate >>>>> work item, but this is not the case now, so good enough the way it is= . >>>>> And back again, it really gets repeated, so will lead to nowhere, >>>>> you've got my arguments and tell that the information, which I'm >>>>> talking about, is not usefull. What can I say more? I can put you >>>>> on my position and start asking questions instead of answering. So, >>>>> why it is not usefull? >>>>=20 >>>> =3D> I explained why the specific information you mentioned was not >>>> useful/useable by the MN and this is what I referred to as unanswered. >>>> Because if you agree with my previous explanations then we don't >>>> need to discuss it further. If you disagree you certainly didn't >>>> tell me why. You have the charge of proof because you want to change >>>> the way MIP works currently, that's all I'm trying to say. >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> /yuri >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: Thursday, June 04, 2009 4:00 AM >>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>> pierrick.seite@orange-ftgroup.com >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of >>>>> flowbindings >>>>>=20 >>>>> Yuri, >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Missing is additional information which may be helpful in making >>>>>> better decision about interface selection by MN. >>>>>> Which information is that I wrote in my previous emails. Back to >>>>>> my examples (not all, do not want to repeat myself). If HA will >>>>>> have changed traffic shaping parameters on one of the incoming or >>>>>> outgoing interfaces, this will be important information for MN to kn= ow. >>>>>> We have agreed already that whether this information important or >>>>>> not, benfitial or not is a matter of standpoint. >>>>>=20 >>>>> =3D> I don't agree or like to think that it's a matter of standpoint. >>>>> That's why I asked you on every point you raised and compared this >>>>> to the MN's knowledge on e2e basis. Once we have "standpoints" then >>>>> we're getting outside the technical realm. The reason I don't think >>>>> it's useful is that this information cannot be used by the MN to >>>>> select a CoA. I've already stated that before and you seemed to >>>>> agree so I don't know why you repeat this as a reason for the HA to >>>>> install filters in the MN. Let me say it >>>>> again: There is no correlation between the routing on the HA's >>>>> upstream interfaces/ISP with the MN's selection of a CoA. >>>>>=20 >>>>>> I consider that knowing more is a benefit and will help to get >>>>>> better result. >>>>>>=20 >>>>>> My point is still the same. I see the reverse rules sending as >>>>>> possibility to provide more information to the MN, thus make MN to >>>>>> get to better decision about interface selection for its flows. >>>>>> This point has not changed since the beginning of the discussion. >>>>>=20 >>>>> =3D> This is why we're not making progress IMO: >>>>>=20 >>>>> 1. The hints you refer to are not the same things as installing >>>>> rules on the MN. Completely different information in fact. You've >>>>> essentially proved that when you suggested that the MN can accept >>>>> or reject them. So, let's not call them rules. The more direct word >>>>> for what you want to send is policies >>>>>=20 >>>>> 2. You didn't provide a valid scenario that we can discuss as to >>>>> why it's needed or how it could work. I've asked numerous questions >>>>> in each email that were not answered (with the exception of the >>>>> last email). It's not possible to progress the discussion without >>>>> answering each others' >>>>> questions. You can go back through the threads and verify this. >>>>>=20 >>>>> 3. If we're sending rules from the HA to the MN and the MN can >>>>> reject those rules then the whole exercise is pointless. You really >>>>> want to send policies not rules. I can imagine those policies being >>>>> one of the inputs that the MN uses to make a decision. I still fail >>>>> to see how anything happening on the HA's upstream interfaces/ISP >>>>> link can possibly influence the MN's decision for CoA selection. >>>>> This is another unanswered question. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>>=20 >>>>>> /yuri >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>> Sent: Wednesday, June 03, 2009 4:09 PM >>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>> pierrick.seite@orange-ftgroup.com >>>>>> Cc: mext@ietf.org >>>>>> Subject: Re: [MEXT] Important considerations for directionality of >>>>>> flowbindings >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 3/06/09 10:47 PM, "Yuri Ismailov" wr= ote: >>>>>>=20 >>>>>>> Ok, see your point, however:-) >>>>>>>=20 >>>>>>> The major difference here is that your are talking about CoA >>>>>>> selection and I'm talking about interface selection. Quite a big >>>>>>> difference. >>>>>>=20 >>>>>> =3D> No, that's not the point really. The point is that there is no >>>>>> relationship between CoA/interface selection on the MN and the >>>>>> upstream ISP for the home network. >>>>>>=20 >>>>>>> I do not see any grounds for MN to select CoA, based on what? >>>>>>> Prefix length? >>>>>>> While selection of an interface is based on expected >>>>>>> characteristics of the communication. Routes (up/down)link in my >>>>>>> opinion do have impact on the characteristics and this is exactly >>>>>>> the information missing in the MN when selecting interface. >>>>>>=20 >>>>>> =3D> There is nothing missing for the MN to make this selection. >>>>>> Please tell us specifically what is missing. You're changing >>>>>> points on me all the time now. >>>>>> Lets stick to one point at a time. What's missing? >>>>>>=20 >>>>>>>=20 >>>>>>> Whenever, MN decides to move a flow, the reason can be anything >>>>>>> but not which CoA it has configured on each interface. >>>>>>>=20 >>>>>>> Another thing is that MN will notice something e2e if and only if >>>>>>> such support is implemented in the MN. >>>>>>=20 >>>>>> =3D> Of course, so what? >>>>>>=20 >>>>>> Moreover, this notice can not be made at IP layer. >>>>>>> TCP fights alone with all problems and never tells to any other >>>>>>> layer what is going on. So what is left? Two options. Add this >>>>>>> support to operating system, which makes its (support) existence >>>>>>> questionable, or to applications, which is even more questionable. >>>>>>=20 >>>>>> =3D> It's interesting that you think it's questionable to add the >>>>>> support to the MN's OS but not questionable to add the support to >>>>>> the HA's OS, which will not lead to the same reliability as if it >>>>>> were done in the MN. It doesn't make sense to me. >>>>>>=20 >>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Well, that's debatable, but this is clearly not a reason to do >>>>>>>>> anything. >>>>>>>>>=20 >>>>>>> Are you serious about that MIP may be broken because of that? >>>>>>=20 >>>>>> =3D> Yes! It's not designed to do what you want to do. Luckily, in >>>>>> this case what you want, IMO, is broken anyway so it's not a problem= . >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>>=20 >>>>>>> /yuri >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>> Sent: Wednesday, June 03, 2009 1:15 PM >>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>> Cc: mext@ietf.org >>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>> of flowbindings >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Still some answers, despite knowing that in your opinion they >>>>>>>> are not benefits. >>>>>>>>=20 >>>>>>>> First of all MIP will not be breaked if the rules will be sent >>>>>>>> in both directions. >>>>>>>=20 >>>>>>> =3D> Well, that's debatable, but this is clearly not a reason to do >>>>>>> anything. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> - Access provider preferences relate to the use of backbone >>>>>>>> provider, which may vary with the time of day. Changing backbone >>>>>>>> provider can make quite big difference for commnication between >>>>>>>> HA (if HA service is provided by the same access provider) and CN(= s). >>>>>>>> The difference can be expressed in, let's say, number of hops, >>>>>>>> load, possibly something else. Such change is an event and may >>>>>>>> have an impact on the overall communication. This can be told >>>>>>>> directly to MN or HA. Direct communication to MN (if accepted as >>>>>>>> benefit:-)) in such case will need standardization. >>>>>>>> Communication of this information to HA does not (I consider this = as a >>>>>>>> benefit). >>>>>>>> HA may act upon that event, and the rest you >>>>>>>> know: rules in reverse direction. >>>>>>>=20 >>>>>>> =3D> There is no need to _tell_ the MN anything. There are two issues >>>>>>> here. >>>>>>> First, changing network conditions are best known e2e. So the MN >>>>>>> will know that anyway based on the traffic running between it and t= he >>>>>>> CN. >>>>>>> The other issue is related to cost for certain times of day. This >>>>>>> is a routing issue in the HA and has nothing to do with which >>>>>>> interface the MN selects. The selected CoA has zero impact on the >>>>>>> HA's upstream selection. Completely irrelevant actually. >>>>>>> Of course, as far as cost on the visited link, the MN knows best. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> - Access provider may set up different parameters for traffic >>>>>>>> shaping for each of HA interfaces. These preferences may vary >>>>>>>> independently of change of backbone provider but dependently on >>>>>>>> the time of day. >>>>>>>> The rest you know, whether it changes somebodies opinion. >>>>>>>=20 >>>>>>> =3D> But again, this has zero effect on CoA selection. The two >>>>>>> issues are completely orthogonal. Selecting CoA1 or CoA2 has zero >>>>>>> impact on the HA's upstream route. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> - I presume that in RO mode this is similar to HA mode, and I'm >>>>>>>> in when it comes to send rules in reverse direction between CN and= MN. >>>>>>>> Benefits of doing that is that any change percieved by CN as >>>>>>>> important to react upon can be expressed in proposal of new rules. >>>>>>>> The sources causing changes may include but not limited to, are >>>>>>>> user, network managemnt events, application generated events, etc. >>>>>>>>=20 >>>>>>>> So feel free to consider this as benefits or not >>>>>>>=20 >>>>>>> =3D> You seem to think that there is a relationship between >>>>>>> upstream routing and CoA selection. That's not the case at all. >>>>>>> These are two different addresses from two different networks. >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>>=20 >>>>>>>> /yuri >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>> Sent: Wednesday, June 03, 2009 11:47 AM >>>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>> Cc: mext@ietf.org >>>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>>> of flowbindings >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 3/06/09 7:33 PM, "Yuri Ismailov" w= rote: >>>>>>>>=20 >>>>>>>>> Hesham, >>>>>>>>>=20 >>>>>>>>> Whenever we talk about sending additional information, the >>>>>>>>> "waste of bandwidth" can be brought up. So I do not have an >>>>>>>>> answer for that besides speculations around it. >>>>>>>>=20 >>>>>>>> =3D> no no, I don't mean it literally, I mean that the message >>>>>>>> doesn't do anything, i.e. Has no benefit. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Speaking about benefits, everybody who knows the area is >>>>>>>>> capable of turning things up side down. I assume it is >>>>>>>>> subjective standpoint of considering things as benefits or >>>>>>>>> disadvantages and all is about to agree or disagree. >>>>>>>>=20 >>>>>>>> =3D> That's fine, I'm asking for benefits in your opinion not >>>>>>>> someone else's. >>>>>>>> It's impossible to discuss this if I can't see any benefits >>>>>>>> because you didn't send any. What you sent were actions that can >>>>>>>> be done by the HA and I responded by saying that the same (or >>>>>>>> more) information is available to the MN. Therefore, if you >>>>>>>> think there are additional benefits to doing this in the HA then >>>>>>>> you need to tell us. >>>>>>>>=20 >>>>>>>> The bottom line is this: MIP works by letting the MN install >>>>>>>> bindings in the HA. If you want things to work in reverse you >>>>>>>> need to justify it. I can't see any justifications because >>>>>>>> you're not answering my questions on your scenarios. So, count >>>>>>>> me out on the reverse direction :). >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> For >>>>>>>>> me those I wrote about are benefits or potential benefits if you = want. >>>>>>>>=20 >>>>>>>> =3D> No you didn't. You wrote about things that can be done. Many >>>>>>>> things can be done by many entities, the question is why the HA >>>>>>>> and not the MN. >>>>>>>>=20 >>>>>>>>> One important thing in the discussion, although mentioned, but >>>>>>>>> forgotten later is that by making rules distribution one way >>>>>>>>> only, we do create limitation for benefits, or potential >>>>>>>>> benefits if this sounds better. >>>>>>>>=20 >>>>>>>> =3D> Well, we won't know what we're missing unless someone tells us. >>>>>>>> So far no one has mentioned the advantages of doing things in >>>>>>>> the reverse direction. >>>>>>>> There is always something missing from a protocol (it's >>>>>>>> engineering), the question us whether it's significant or worth >>>>>>>> the trouble. >>>>>>>>=20 >>>>>>>> Hesham >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> /yuri >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>> Sent: Wednesday, June 03, 2009 10:10 AM >>>>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>> Cc: mext@ietf.org >>>>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>>>> of flowbindings >>>>>>>>>=20 >>>>>>>>> Yuri, >>>>>>>>>=20 >>>>>>>>> I can't parse those events you refer to. I'l answer both emails h= ere. >>>>>>>>> First the events you refer to: >>>>>>>>>=20 >>>>>>>>>>> - network condition towards CN(s) >>>>>>>>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>>>>>>>=20 >>>>>>>>> =3D> What's the event? A change in those conditions? The MN knows >>>>>>>>> the conditions of the e2e path as well as or better than the HA. >>>>>>>>> What is the benefit of having the HA send a hint and how >>>>>>>>> reliable is that hint anyway? >>>>>>>>>=20 >>>>>>>>>>> - Access provider (any access, not necessarily wireless) who >>>>>>>>>>> offeres HA services preferences change >>>>>>>>>=20 >>>>>>>>> =3D> Preferences change to what?? How does it know if such change >>>>>>>>> works for the MN at all? This is way too vague to be able to >>>>>>>>> discuss tradeoffs. >>>>>>>>>=20 >>>>>>>>>>> - Change of the access provider traffic to another backbone >>>>>>>>>>> provider due to the time of the day. >>>>>>>>>>> - Traffic condition on HA interface, which accepts traffic >>>>>>>>>>> from MN if MN sends on some particular local interface >>>>>>>>>=20 >>>>>>>>> =3D> These are path changes. The HA has _no idea_ how such a >>>>>>>>> change affects each MN/CN combination and it's "hint" can cause >>>>>>>>> more problems than it solves. BTW, if you're talking about >>>>>>>>> hints then we're no longer talking about installing bindings in >>>>>>>>> the MN. This is a different topic. MIP doesn't transfer hints, >>>>>>>>> it pretty much sends "orders" >>>>>>>>> from one end to another. >>>>>>>>>=20 >>>>>>>>> Now to the actions required by the MN: >>>>>>>>>=20 >>>>>>>>>> - reject, >>>>>>>>>> - re-evaluate and reject >>>>>>>>>> - re-evaluate and accept >>>>>>>>>> - accept >>>>>>>>>=20 >>>>>>>>> =3D> First, by assuming that the MN can reject the "hint" as you >>>>>>>>> call it you invalidate the whole argument for the HA to install r= ules. >>>>>>>>> Rejecting a hint or even evaluating it means that the MN knows mo= re. >>>>>>>>> Therefore, the HA's hint is a complete waste of bandwidth. >>>>>>>>>=20 >>>>>>>>> I'm still confused about the _benefits_ you see here. Or are >>>>>>>>> you assuming that the MN can't know those hints without the >>>>>>>>> HA's involvement? But if you're assuming that, then how can it >>>>>>>>> reject the hints? This whole proposal makes no sense to me at >>>>>>>>> all. Not to mention the complexity you implicitly assume in >>>>>>>>> order to generate those, hopefully reliable, hints. >>>>>>>>>=20 >>>>>>>>> Hesham >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 3/06/09 5:23 PM, "Yuri Ismailov" >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Hesham, >>>>>>>>>>=20 >>>>>>>>>> In my view these are events not scenarious. These events are >>>>>>>>>> known by HA but not MN. If HA acts upon events, given that it >>>>>>>>>> knows somewhat more about MN, not only IP addresses, it (HA) >>>>>>>>>> can generate new rules and send them as hint to MN. Back >>>>>>>>>> again, MN has four >>>>>>>>>> options: >>>>>>>>>>=20 >>>>>>>>>> The benefit will be obviously that the new rules (if accepted) >>>>>>>>>> may llead to a better overall communication characteristics. >>>>>>>>>>=20 >>>>>>>>>> /yuri >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> =3D> I'm trying to understand what you mean above. These are all >>>>>>>>>> scenarios, the question is: What is the benefit for the HA to >>>>>>>>>> transfer rules? The HA will not know the path between the MN >>>>>>>>>> and CN more than either node does. So I don't understand what >>>>>>>>>> _benefits_ you see here. >>>>>>>>>>=20 >>>>>>>>>> Hesham >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Pretty much sure that there are more examples and I encourage >>>>>>>>>>> to think about those not from MN point of view but rather >>>>>>>>>>> from the HA service provider. >>>>>>>>>>>=20 >>>>>>>>>>> /yuri >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>>>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>>>> Cc: mext@ietf.org >>>>>>>>>>> Subject: Re: [MEXT] Important considerations for >>>>>>>>>>> directionality of flowbindings >>>>>>>>>>>=20 >>>>>>>>>>> Yuri, >>>>>>>>>>>=20 >>>>>>>>>>> It is just rules TRANSFER which is the matter of MIP. So >>>>>>>>>>> where >>>>>>>>>>>> is the logic when saying that MN to HA rules transfer is a >>>>>>>>>>>> practical engineering and HA to MN is an academic interest? >>>>>>>>>>>=20 >>>>>>>>>>> =3D> I think we've (I'm including myself) highlighted several >>>>>>>>>>> reasons for why it makes little sense to transfer rules from >>>>>>>>>>> HA to MN. >>>>>>>>>>> Instead of rat-holing on theory Vs practice, you (or others >>>>>>>>>>> advocating the other direction) need to come up with reasons >>>>>>>>>>> for doing things this way. This way we can think like >>>>>>>>>>> engineers about tradeoffs. >>>>>>>>>>> Absent that, I don't see any point in having theory Vs >>>>>>>>>>> practice high level discussions, which will lead nowhere. >>>>>>>>>>>=20 >>>>>>>>>>> Hesham >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards >>>>>>>>>>>> Yuri >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>>>>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>>>>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>>>>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>>>>>>>> Subject: Re: [MEXT] Important considerations for >>>>>>>>>>>> directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi Pierrick, >>>>>>>>>>>>=20 >>>>>>>>>>>> On Jun 2, 2009, at 4:11 PM, >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>> Please see inline comment. >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>> Pierrick >>>>>>>>>>>>=20 >>>>>>>>>>>> ________________________________________ >>>>>>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>>> De la part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:3= 5 =C0 : >>>>>>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important=20 >>>>>>>>>>>> considerations for directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham, >>>>>>>>>>>> This is nice story and makes some sense for the discssion,=20 >>>>>>>>>>>> however some details are ommited. In your adventure with=20 >>>>>>>>>>>> the helpdesk, it (the >>>>>>>>>>>> helpdesk) is a third party service and thus your=20 >>>>>>>>>>>> conclusions make sence. >>>>>>>>>>>> Think of the situation when superior of a heldesk person=20 >>>>>>>>>>>> will tell him/her to check access point in some room. Would=20 >>>>>>>>>>>> it be the same reaction? I assume not. By that I mean that=20 >>>>>>>>>>>> if, for example, I'll install home agent in my home=20 >>>>>>>>>>>> network, I can make it know anything I want about MN, and=20 >>>>>>>>>>>> more intresting is that how I will do it, does not require=20 >>>>>>>>>>>> any standardization. >>>>>>>>>>>> In other words, I'm superior of my HA. >>>>>>>>>>>> This situation is not unthinkable, I personally believe=20 >>>>>>>>>>>> that this is much more efficient way of using HA=20 >>>>>>>>>>>> fnctionality as opposed to big service providers who will=20 >>>>>>>>>>>> have to fight with scalability and performance. >>>>>>>>>>>> However, one does not exclude another. >>>>>>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> The difference between policy and rules is not only a=20 >>>>>>>>>>>> matter of conversion. A policy, is a static, or=20 >>>>>>>>>>>> quasi-static, set of guidance for the MN (e.g use access=20 >>>>>>>>>>>> network X for application type >>>>>>>>>>>> A,...) while a rule update requires to be more dynamic. I mean= : >>>>>>>>>>>> eventually a policy could be updated depending on network=20 >>>>>>>>>>>> condition (e.g if X overloaded, use access network Y for=20 >>>>>>>>>>>> application type A,...) but a rule reacts on local triggers (e= .g. >>>>>>>>>>>> modification of the radio link >>>>>>>>>>>> quality) with a shorter period of variation. So, IMHO,=20 >>>>>>>>>>>> there is no requirement for updating policy on a short=20 >>>>>>>>>>>> period and out-of-band mechanism can be used (e.g. IEEE=20 >>>>>>>>>>>> 802.21 in push mode,...). >>>>>>>>>>>>=20 >>>>>>>>>>>> Fully agree! >>>>>>>>>>>> This is why I do not support the exchange of rules from the=20 >>>>>>>>>>>> HA to the MN. >>>>>>>>>>>> Policies may be exchanged from the HA to the MN, but MIP is=20 >>>>>>>>>>>> definitely not the protocol to transport them. >>>>>>>>>>>>=20 >>>>>>>>>>>> Nicolas >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> My 2 cents... >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Is there any reason to restrict where such convertion takes pl= ace? >>>>>>>>>>>> True >>>>>>>>>>>> that a HA does not know what is going on in the access=20 >>>>>>>>>>>> network, on the other hand HA may know what is the network=20 >>>>>>>>>>>> condition between HA and correspondent node. Either of this=20 >>>>>>>>>>>> information is important, if not equally important. >>>>>>>>>>>> It is not really difficult to let an MN to reject rules=20 >>>>>>>>>>>> sent by HA, which in my view would be quite natural. This=20 >>>>>>>>>>>> implies that HA must follow the rules installed by MN until=20 >>>>>>>>>>>> explicit acceptance has been received from MN. >>>>>>>>>>>> Such procedure is very similar to an MN beahviour when=20 >>>>>>>>>>>> initiating new BU, where MN is not supposed to send any=20 >>>>>>>>>>>> traffic before BU confirmation. >>>>>>>>>>>> BTW, what is the numerical representation of "rough consensus"= ? >>>>>>>>>>>> I assume is when majority is for, is it so? >>>>>>>>>>>> Yuri >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>>> On Behalf Of Hesham Soliman >>>>>>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>>>>>> To: mext >>>>>>>>>>>> Subject: [MEXT] Important considerations for directionality=20 >>>>>>>>>>>> of flow bindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>> I've always been a fan of the IETF's tradition of rough=20 >>>>>>>>>>>> concensus (as opposed to voting). To me, this implies that=20 >>>>>>>>>>>> you need to get your point across and get other people to=20 >>>>>>>>>>>> see that point of view. >>>>>>>>>>>> As opposed to other organisations that require their=20 >>>>>>>>>>>> members to vote and end up with rigid political positions. >>>>>>>>>>>>=20 >>>>>>>>>>>> The chairs asked us about the directionality question of=20 >>>>>>>>>>>> the flows bindings. >>>>>>>>>>>> On the charter question, I said that the charter doesn't=20 >>>>>>>>>>>> need to mention how a solution should work, but rather what=20 >>>>>>>>>>>> problem needs to be solved. >>>>>>>>>>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>>>>>>>>>> transferring rules "between" the MN and HA without=20 >>>>>>>>>>>> mentioning directions. >>>>>>>>>>>>=20 >>>>>>>>>>>> Nevertheless, we still need to agree on identifying the=20 >>>>>>>>>>>> requirement for the solution. And when it comes to this,=20 >>>>>>>>>>>> I'm strongly against voting and I'll practice this by=20 >>>>>>>>>>>> explaining in this email why I think rules can not be=20 >>>>>>>>>>>> transferred from the HA to the MN and that the only=20 >>>>>>>>>>>> direction that makes sense in MIP is >>>>>>>>>>>> MN->HA. I'll deliberately ignore arguments like "some=20 >>>>>>>>>>>> MN->people want >>>>>>>>>>>> this" or "an SDO wants this". They fall under the=20 >>>>>>>>>>>> "meaningless words" >>>>>>>>>>>> category and I'm incapable of discussing them because they=20 >>>>>>>>>>>> come with voting attitudes. They all need to be justified=20 >>>>>>>>>>>> if the WG wants to have a technical _discussion_. >>>>>>>>>>>>=20 >>>>>>>>>>>> Here are my reasons: >>>>>>>>>>>>=20 >>>>>>>>>>>> 1. The HA does not know whether a CoA is tied to a certain=20 >>>>>>>>>>>> access technology. It is one thing for the HA to send a=20 >>>>>>>>>>>> message saying "forward port 80 traffic on a wifi link" (a >>>>>>>>>>>> policy) and a completely different thing to say "forward=20 >>>>>>>>>>>> port 80 traffic using CoA 3ffe::1" >>>>>>>>>>>> (a rule). >>>>>>>>>>>>=20 >>>>>>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem now? >>>>>>>>>>>> The problem is that the HA has no idea about dynamic=20 >>>>>>>>>>>> changes on that wifi link. It doesn't know if it's=20 >>>>>>>>>>>> congested, it doesn't know what application is using port=20 >>>>>>>>>>>> 80 (it doesn't have to be web >>>>>>>>>>>> traffic) or port 8000 for that matter and doesn't even know=20 >>>>>>>>>>>> if the AP of that wifi link works at all. >>>>>>>>>>>> Finally, it >>>>>>>>>>>> doesn't know the user's policies or other admin policies=20 >>>>>>>>>>>> for that MN. >>>>>>>>>>>> This type of information needs to be sent regularly because=20 >>>>>>>>>>>> it changes all the time and requires serious cross layer=20 >>>>>>>>>>>> integration including sometimes layer 8 integration! It's=20 >>>>>>>>>>>> completely impractical. >>>>>>>>>>>>=20 >>>>>>>>>>>> 3. If the HA installed rules in the MN, what happens if the=20 >>>>>>>>>>>> MN wants to change those rules. Say the wifi link went=20 >>>>>>>>>>>> down, or the MN's wifi interface went down and it wants to=20 >>>>>>>>>>>> move that traffic to another interface. Would the HA reject=20 >>>>>>>>>>>> such move? >>>>>>>>>>>> Does the MN have to justify to the HA why it needs to move=20 >>>>>>>>>>>> traffic? Does that involve writing a letter perhaps? >>>>>>>>>>>> If you say "well in that case, the HA should let the MN=20 >>>>>>>>>>>> move the traffic" >>>>>>>>>>>> then I'll ask you: what's the point of having the HA=20 >>>>>>>>>>>> install this stuff if it has no authority and how does it=20 >>>>>>>>>>>> know the reason for the MN's movement of the flow? >>>>>>>>>>>> The way to control how users do things is to incentivise=20 >>>>>>>>>>>> them with charging models and show them that things work=20 >>>>>>>>>>>> better on certain technologies, not by installing rules=20 >>>>>>>>>>>> that can't be followed. It's a broken mindset and we've=20 >>>>>>>>>>>> known that it's broken for a long time. >>>>>>>>>>>>=20 >>>>>>>>>>>> 4. Some people mentioned that the HA should be able to=20 >>>>>>>>>>>> revoke flows on the MN. I'm perfectly fine with that, just=20 >>>>>>>>>>>> extend the binding revocation draft to handle flows and the=20 >>>>>>>>>>>> rest is pretty straight forward. >>>>>>>>>>>>=20 >>>>>>>>>>>> Finally, I'll indulge in a true story that happened to me a=20 >>>>>>>>>>>> few years ago when I found that my wifi link wasn't working=20 >>>>>>>>>>>> in a hotel (no >>>>>>>>>>>> radio) >>>>>>>>>>>> and called the help desk. He insisted that the link was up=20 >>>>>>>>>>>> an I insisted that it wasn't. When I asked him to tell me=20 >>>>>>>>>>>> how he knows the link is up he said: I can ping the AP! Of=20 >>>>>>>>>>>> course after another >>>>>>>>>>>> 5 minutes of trying to convince him that pinging the AP=20 >>>>>>>>>>>> doesn't mean the radio is actually working he sent someone=20 >>>>>>>>>>>> to the hotel who in turn realised that the radio was not worki= ng. >>>>>>>>>>>> For those people who want rules to be transferred from the=20 >>>>>>>>>>>> HA to the MN, please think of your HA as this help desk=20 >>>>>>>>>>>> person, i.e. >>>>>>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>>>>>=20 >>>>>>>>>>>> I hope this helps with the realisation that decisions can't=20 >>>>>>>>>>>> be made here based on voting and that there is little merit=20 >>>>>>>>>>>> to transferring rules from the HA to the MN. Policies can=20 >>>>>>>>>>>> be transferred without any problems, but not rules. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From yuri.ismailov@ericsson.com Tue Jun 9 00:07:23 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36BF03A6DD7 for ; Tue, 9 Jun 2009 00:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.082 X-Spam-Level: X-Spam-Status: No, score=-8.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 DY2+8mOTy5r9 for ; Tue, 9 Jun 2009 00:07:19 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B6CC83A698D for ; Tue, 9 Jun 2009 00:07:18 -0700 (PDT) X-AuditID: c1b4fb3e-b7b2dae00000205f-fb-4a2e0a2a1eb7 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 2E.82.08287.A2A0E2A4; Tue, 9 Jun 2009 09:07:22 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 09:07:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Jun 2009 09:07:20 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQ References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 09 Jun 2009 07:07:21.0675 (UTC) FILETIME=[EEF699B0:01C9E8D0] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 07:07:23 -0000 Hesham, below is my attempt to understand what the following means (not = an easy task though) =20 > =3D> So now that we agree that we are only talking about CoAs then I = don't see any meaningful information coming from the HA. Hints about = upstream > routing changes ...etc are relevant to HoA selection (even if the HoA = is not tied to a physical interface it doesn't matter). This is an=20 > interesting problem to discuss but I want to be clear on its context. = So to summarise my opinion: > HA-> MN hints (not rules) may be relevant for intial HoA selection for > certain connections. The types of hints and how to formulate this in a = global manner can lead to interesting work (although it's a complex=20 > problem). However, this information is not in anyway relevant to = CoA/physical interface selection on the MN. First, is that we have agreed already that we are talking about = interfaces. Yes, we are talking about interfaces configured with CoA. = Interfaces configured with HoA does not give any information about = characteristices of interfaces configured with CoA, thus choosing HoA or = HA can not provide any meaningful information about access = characteristics. Thus it is not clear at all where from comes idea about = relevance to HA selection. In all my examples (e.g. the latest one about broadband operators) it = does not matter which HA (HoA) is used. All what matters is which access = MN uses and if there was traffic shaping policy applied to that access = by an access provider. We have agreed that MN can not know about the = later. HA can. Second, is that we are talking about sending rules from HA to MN. I call = these rules hints, because and only because in my view MN should have = rights to ignore the rules from HA. Both transportwise and contentwise, = we are still talking about rules. At the moment I do not see any = specific need for specific types of hints. Information about the fact that up/down link from/to HA for a particular = interface was downgraded is very relevant for MN because based on this = information MN can select another interface for some of its flows and = make correspondent move. If this is not the case then what is the = objactive of interfaces selection? If better choice of interface for = applications is not an objective then why bother about flow mobility at = all? Regards Yuri -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Monday, June 08, 2009 4:29 PM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings On 9/06/09 12:12 AM, "Yuri Ismailov" wrote: > =20 > =3D> Yes but I still think you're talking about something else. The=20 > interface you're talking about seems to be associated with the HoA.=20 > This is the only case where I can see the relevance of HA hints (not=20 > rules). The interfaces I'm talking about and discussed in the context=20 > of flow bindings are those associated with CoAs. There is nothing=20 > coming from the HA about its links ...etc that can have any impact on = CoA selection. >=20 > Hesham > here I tend to agree. I actually ment interfaces with CoA, but now=20 > realized that in such configuration, where each of interfaces has it's = > own HA configured, it is most likely that each of interfaces will have = different HoA. > Once this is the case then moving a flow between those interfaces will = > lead to change of HoA. As we are in MIP context, I would better avoid=20 > that. In the whole discussion I mean interafces with CoA because=20 > selection of HoA and/or associated to it interface can not be based on = > physical characteristics of that interface. =3D> Sounds fine to me. >=20 > So the valid and meaningful scenario is moving flow(s) between=20 > interfaces associated with the same HA, whether all interfaces of the=20 > MN or some of them will be configured this way does not really matter. >=20 > Fine with me. Should we finalize then? As I see it, once there is a=20 > meaningful information, which can be sent in HA -> MN direction, then=20 > MN can use it for re-evaluting policies and producing the new set of=20 > rules. Definetely not at all times new rules will be produced, they=20 > may stay unchanged, as it will be the case with many other events = taking place at either side: MN or HA. >=20 > Is that correct? =3D> So now that we agree that we are only talking about CoAs then I = don't see any meaningful information coming from the HA. Hints about = upstream routing changes ...etc are relevant to HoA selection (even if = the HoA is not tied to a physical interface it doesn't matter). This is = an interesting problem to discuss but I want to be clear on its context. = So to summarise my opinion: HA-> MN hints (not rules) may be relevant for intial HoA selection for certain connections. The types of hints and how to formulate this in a = global manner can lead to interesting work (although it's a complex = problem). However, this information is not in anyway relevant to = CoA/physical interface selection on the MN. Hesham >=20 > Regards > Yuri >=20 >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Monday, June 08, 2009 2:00 PM > To: Yuri Ismailov; Nicolas Montavont;=20 > pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of=20 > flowbindings >=20 > Yuri, >=20 > I think we're getting close here. >=20 >=20 > On 8/06/09 6:29 PM, "Yuri Ismailov" = wrote: >=20 >> Hesham, It looks like that the only point of disagreement is about=20 >> changing HA and mapping between HA and access. >> Some explanations of what I mean below: >>=20 >>=20 >> 1. Changing HA. >> As it follows from group charter change of HA is in the plans of MEXT = >> WG. I assume that this is going to be a separate work item because=20 >> the reason specified for that is very specific and relates to=20 >> deployment more than to flow mobility. Do not want to speculate,=20 >> about this right now but the change of HA does not necessarily means = change of rules. >> So the proposal is to not to discuss change of HA as you suggested. >=20 > =3D> Agreed. >=20 >>=20 >> 2. In my example I do not mean change of HA as an explicit procedure=20 >> specified separately. One confirmation to that is that single HA for=20 >> all interfaces is included and valid option. Based on the HA -> MN=20 >> exchange, the MN may perform interface selection procedure and may=20 >> choose another interface for some flow(s). In multiple HA case it=20 >> will result of the rules update MN -> HA to the HA which is relevant=20 >> for the new interface chosen for flows. Please notice, There is=20 >> nothing about HA change, only about interface selection. >=20 > =3D> Yes but I still think you're talking about something else. The=20 > interface you're talking about seems to be associated with the HoA.=20 > This is the only case where I can see the relevance of HA hints (not=20 > rules). The interfaces I'm talking about and discussed in the context=20 > of flow bindings are those associated with CoAs. There is nothing=20 > coming from the HA about its links ...etc that can have any impact on = CoA selection. >=20 >>=20 >> 3. I do not map HA and access. It is allowed for any access provider=20 >> to offer HA service and once this is the case it will be so. Thus an=20 >> MN can have multiple HA configured for the use on different = interfaces. >=20 > =3D> Good, we agree on that too. >=20 > Hesham >=20 >>=20 >> Regards >> Yuri >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Friday, June 05, 2009 4:18 PM >> To: Yuri Ismailov; Nicolas Montavont;=20 >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of=20 >> flowbindings >>=20 >>=20 >>=20 >>> First is that I assume that we have simulteneous multiaccess in=20 >>> mind, i.e. MN has more than one interface to choose from for its=20 >>> flows. If this is not the case then I will stop the discussion. This = >>> assumption is based on the fact that we are (I hope at least) = discussing flow mobility. >>=20 >> =3D> Sure. >>=20 >>>=20 >>> Secondly, I consider that MN chooses an interface but not CoA. I=20 >>> gave a though about that and did not come up with any information=20 >>> which can be derived from CoA in order to choose it. An interface=20 >>> has at least expected characteristics, thus can be a subject of=20 >>> choice. Any clarification about that would be appreciated. >> =3D> An application would choose an interface, but of course the IP=20 >> stack selects the corresponding address. I'm sure there is no=20 >> disagreement there. >>=20 >>>=20 >>> Next assumptions are about possible configurations of HA >>> - Single HA for all interfaces configured in the mobile. HA can=20 >>> belong to any of the access providers of each of access technology=20 >>> used by MN. >>=20 >> =3D> Ok. >>=20 >>>=20 >>> - One HA per access or set of accesses, which is subset of all=20 >>> access techologies presented or potentially may be presented=20 >>> (detached >>> devices) in MN. >>=20 >> =3D> Now you're getting into a different problem space from flow = mobility. >> This is why I wanted you to break the scenario down. We are not=20 >> dealing with multiple HoAs in this work item, we're dealing with=20 >> multiple CoAs, i.e. One HoA. >>=20 >>> Anticipating numerous questions about that can say that I looked at=20 >>> such configuration and did not find anything strange with it, i.e. >>> (1) it works, >>> (2) it does not require any change to MIP or any other of its=20 >>> extensions. (3) Configuration is performed per interface and does=20 >>> not introduce any ambiguities. (4) it is natural for access provider = >>> to offer HA service. >>=20 >> =3D> Yes of course it works but as I read this I'm guessing that you=20 >> want the MN to change HoA. This is not the problem we're discussing=20 >> in this WG. >> Another issue, I'm not comfortable with the wording of "HA per = access" >> because they're not tied to access. Let's just say there are multiple = >> Has and not associate it with an access. >>=20 >>>=20 >>> - "Residential" HA. Assumption is that it can be either one of HA's=20 >>> or a single HA for all types of accesses. This is the matter of MN=20 >>> configuration. >>> "Residential". >>=20 >> =3D> Please don't tie HA to access. >>=20 >>>=20 >>> - Any HA may have multiple interfaces, e.g. "residential" HA may be=20 >>> connected to mobile broadband, DSL, etc. >>=20 >> =3D> sure >>=20 >>>=20 >>> Next assumption comes from the example (e.g. latest one) >>> - Traffic shaping is applied in both directions (up/down) link (in=20 >>> practice this is the case). >>> - Traffic shaping (TS) is applied to user subscription. In other=20 >>> words TS is applied to packets belonging to a particular=20 >>> subscription but not to an aggregated traffic on gateway interfaces. = >>> HA is not necessary (however, nothing prevents from that) a gateway=20 >>> where TS is applied. >>>=20 >>>=20 >>> I hope that I have not missed something, although it may be = possible. >>> If we can agree on that or correct if something is wrong here and=20 >>> agree later then we know how to proceed further on >>=20 >> =3D> Your scenario is fine (with the wording changes for tying Has to = access). >> But I want to pre-empt any suggestion that the HA will tell the MN to = >> use a different HoA. This is very possible but it's not the problem=20 >> being discussed here. It may well be something for charter discussion = >> but it has zero impact on flow bindings for multiple CoAs. >>=20 >> Hesham >>=20 >>>=20 >>> /yuri >>>=20 >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Friday, June 05, 2009 11:37 AM >>> To: Yuri Ismailov; Nicolas Montavont;=20 >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>> flowbindings >>>=20 >>> Yuri, >>>=20 >>>=20 >>>> Still not clear for me why you call scenarious invalid? >>>> Some broadband providers (this is used in practice) have quota on=20 >>>> the amount of traffic sent by users. Once quota is exceeded=20 >>>> provider downgardes outgoing traffic from its network to 64Kbs=20 >>>> (this figure is the real example from real provider). Such=20 >>>> combination of to paths, where one is high speed, lets say 10 Mbs=20 >>>> and another one is 64Kbs is quite crusual to apps running on top of = TCP. >>>> Not for all types of traffic though. >>>=20 >>> =3D> Yes I know the scenario but I keep saying to you that the = change=20 >>> in upstream routing in the HA has nothing to do with CoA selection=20 >>> by the MN in the visited network. If anything, you want the MN to=20 >>> change it's HoA depending on how the switch to another upstream ISP = works. >>> It's a completely irrelevant issue to this discussion. Do you agree? >>> If not why not? I really want to see an answer to this point. >>>=20 >>> =20 >>>=20 >>>=20 >>>>=20 >>>> MN can not know about this situation. Nobody will send this=20 >>>> information to MN. >>>=20 >>> =3D> Yes and if it knows what will it do??? If you can answer that = you=20 >>> will fix the deadlock we have. >>>=20 >>>> That means that MN will choose its interfaces based on its=20 >>>> knowledge about 10Mbs link capabilities. >>>=20 >>> =3D> You're talking about two different things. The MN doesn't = choose=20 >>> the HA's outgoing interface! What am I missing? >>>=20 >>> Obtaining this isnformation from HA is quite >>>> significant to make a better decision about choice of interfaces=20 >>>> for its flows. >>>> This is concrete example of what happens in the reality. >>>> Do you consider that this information will be useless for MN? >>>=20 >>> =3D> Completely useless. Unless I'm missing something in your = scenario. >>> Just write down step by step what will happen and include messages.=20 >>> I don't see how this can possibly be relevant to the MN. >>>=20 >>> Hesham >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> /yuri >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Thursday, June 04, 2009 4:38 PM >>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>>> flowbindings >>>>=20 >>>> Yuri, >>>>=20 >>>>=20 >>>> On 5/06/09 12:01 AM, "Yuri Ismailov" = wrote: >>>>=20 >>>>> Hesham, >>>>>=20 >>>>> I provided several scenarious which you said are invalid. This is=20 >>>>> where my conclusion about standpoint comes from. >>>>> Whether you call hints policies or rules it does not change what=20 >>>>> information can be provided by HA to MN. >>>>=20 >>>> =3D> It changes the outcome for the work item we're discussing. I'm = >>>> trying to come to a conclusion on this and there is a huge=20 >>>> difference between transferring policies and installing flow = bindings. >>>>=20 >>>>> By sending rules HA does not install anything in MN. Likewise, MN=20 >>>>> does not install rules in HA, it informs HA about currently made = choices. >>>>> As I remember rules will not be valid until proper Ack arrival,=20 >>>>> which for me means that may not be instantiated at all. >>>>> Niether rules nor polices are specific to MIP. As I wrote those=20 >>>>> can be exchanged between hosts without any MIP implementation,=20 >>>>> just for access selection purposes. Once it was decided to make it = >>>>> as part of MIP protocol, I'm fine with that. Do not have any idea=20 >>>>> to discuss this, while personally consider that the work on rules=20 >>>>> transfer can very well fit into the MEXT group but as a separate=20 >>>>> work item, but this is not the case now, so good enough the way it = is. >>>>> And back again, it really gets repeated, so will lead to nowhere,=20 >>>>> you've got my arguments and tell that the information, which I'm=20 >>>>> talking about, is not usefull. What can I say more? I can put you=20 >>>>> on my position and start asking questions instead of answering.=20 >>>>> So, why it is not usefull? >>>>=20 >>>> =3D> I explained why the specific information you mentioned was not = >>>> useful/useable by the MN and this is what I referred to as = unanswered. >>>> Because if you agree with my previous explanations then we don't=20 >>>> need to discuss it further. If you disagree you certainly didn't=20 >>>> tell me why. You have the charge of proof because you want to=20 >>>> change the way MIP works currently, that's all I'm trying to say. >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> /yuri >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: Thursday, June 04, 2009 4:00 AM >>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>> pierrick.seite@orange-ftgroup.com >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of = >>>>> flowbindings >>>>>=20 >>>>> Yuri, >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Missing is additional information which may be helpful in making=20 >>>>>> better decision about interface selection by MN. >>>>>> Which information is that I wrote in my previous emails. Back to=20 >>>>>> my examples (not all, do not want to repeat myself). If HA will=20 >>>>>> have changed traffic shaping parameters on one of the incoming or = >>>>>> outgoing interfaces, this will be important information for MN to = know. >>>>>> We have agreed already that whether this information important or = >>>>>> not, benfitial or not is a matter of standpoint. >>>>>=20 >>>>> =3D> I don't agree or like to think that it's a matter of = standpoint. >>>>> That's why I asked you on every point you raised and compared this = >>>>> to the MN's knowledge on e2e basis. Once we have "standpoints"=20 >>>>> then we're getting outside the technical realm. The reason I don't = >>>>> think it's useful is that this information cannot be used by the=20 >>>>> MN to select a CoA. I've already stated that before and you seemed = >>>>> to agree so I don't know why you repeat this as a reason for the=20 >>>>> HA to install filters in the MN. Let me say it >>>>> again: There is no correlation between the routing on the HA's=20 >>>>> upstream interfaces/ISP with the MN's selection of a CoA. >>>>>=20 >>>>>> I consider that knowing more is a benefit and will help to get=20 >>>>>> better result. >>>>>>=20 >>>>>> My point is still the same. I see the reverse rules sending as=20 >>>>>> possibility to provide more information to the MN, thus make MN=20 >>>>>> to get to better decision about interface selection for its = flows. >>>>>> This point has not changed since the beginning of the discussion. >>>>>=20 >>>>> =3D> This is why we're not making progress IMO: >>>>>=20 >>>>> 1. The hints you refer to are not the same things as installing=20 >>>>> rules on the MN. Completely different information in fact. You've=20 >>>>> essentially proved that when you suggested that the MN can accept=20 >>>>> or reject them. So, let's not call them rules. The more direct=20 >>>>> word for what you want to send is policies >>>>>=20 >>>>> 2. You didn't provide a valid scenario that we can discuss as to=20 >>>>> why it's needed or how it could work. I've asked numerous=20 >>>>> questions in each email that were not answered (with the exception = >>>>> of the last email). It's not possible to progress the discussion=20 >>>>> without answering each others' >>>>> questions. You can go back through the threads and verify this. >>>>>=20 >>>>> 3. If we're sending rules from the HA to the MN and the MN can=20 >>>>> reject those rules then the whole exercise is pointless. You=20 >>>>> really want to send policies not rules. I can imagine those=20 >>>>> policies being one of the inputs that the MN uses to make a=20 >>>>> decision. I still fail to see how anything happening on the HA's=20 >>>>> upstream interfaces/ISP link can possibly influence the MN's = decision for CoA selection. >>>>> This is another unanswered question. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>>=20 >>>>>> /yuri >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>> Sent: Wednesday, June 03, 2009 4:09 PM >>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>> pierrick.seite@orange-ftgroup.com >>>>>> Cc: mext@ietf.org >>>>>> Subject: Re: [MEXT] Important considerations for directionality=20 >>>>>> of flowbindings >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 3/06/09 10:47 PM, "Yuri Ismailov" = wrote: >>>>>>=20 >>>>>>> Ok, see your point, however:-) >>>>>>>=20 >>>>>>> The major difference here is that your are talking about CoA=20 >>>>>>> selection and I'm talking about interface selection. Quite a big = >>>>>>> difference. >>>>>>=20 >>>>>> =3D> No, that's not the point really. The point is that there is = no=20 >>>>>> relationship between CoA/interface selection on the MN and the=20 >>>>>> upstream ISP for the home network. >>>>>>=20 >>>>>>> I do not see any grounds for MN to select CoA, based on what? >>>>>>> Prefix length? >>>>>>> While selection of an interface is based on expected=20 >>>>>>> characteristics of the communication. Routes (up/down)link in my = >>>>>>> opinion do have impact on the characteristics and this is=20 >>>>>>> exactly the information missing in the MN when selecting = interface. >>>>>>=20 >>>>>> =3D> There is nothing missing for the MN to make this selection. >>>>>> Please tell us specifically what is missing. You're changing=20 >>>>>> points on me all the time now. >>>>>> Lets stick to one point at a time. What's missing? >>>>>>=20 >>>>>>>=20 >>>>>>> Whenever, MN decides to move a flow, the reason can be anything=20 >>>>>>> but not which CoA it has configured on each interface. >>>>>>>=20 >>>>>>> Another thing is that MN will notice something e2e if and only=20 >>>>>>> if such support is implemented in the MN. >>>>>>=20 >>>>>> =3D> Of course, so what? >>>>>>=20 >>>>>> Moreover, this notice can not be made at IP layer. >>>>>>> TCP fights alone with all problems and never tells to any other=20 >>>>>>> layer what is going on. So what is left? Two options. Add this=20 >>>>>>> support to operating system, which makes its (support) existence = >>>>>>> questionable, or to applications, which is even more = questionable. >>>>>>=20 >>>>>> =3D> It's interesting that you think it's questionable to add the = >>>>>> support to the MN's OS but not questionable to add the support to = >>>>>> the HA's OS, which will not lead to the same reliability as if it = >>>>>> were done in the MN. It doesn't make sense to me. >>>>>>=20 >>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Well, that's debatable, but this is clearly not a reason to do = >>>>>>>>> anything. >>>>>>>>>=20 >>>>>>> Are you serious about that MIP may be broken because of that? >>>>>>=20 >>>>>> =3D> Yes! It's not designed to do what you want to do. Luckily, = in=20 >>>>>> this case what you want, IMO, is broken anyway so it's not a = problem. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>>=20 >>>>>>> /yuri >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>> Sent: Wednesday, June 03, 2009 1:15 PM >>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>> Cc: mext@ietf.org >>>>>>> Subject: Re: [MEXT] Important considerations for directionality=20 >>>>>>> of flowbindings >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Still some answers, despite knowing that in your opinion they=20 >>>>>>>> are not benefits. >>>>>>>>=20 >>>>>>>> First of all MIP will not be breaked if the rules will be sent=20 >>>>>>>> in both directions. >>>>>>>=20 >>>>>>> =3D> Well, that's debatable, but this is clearly not a reason to = >>>>>>> do anything. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> - Access provider preferences relate to the use of backbone=20 >>>>>>>> provider, which may vary with the time of day. Changing=20 >>>>>>>> backbone provider can make quite big difference for=20 >>>>>>>> commnication between HA (if HA service is provided by the same = access provider) and CN(s). >>>>>>>> The difference can be expressed in, let's say, number of hops,=20 >>>>>>>> load, possibly something else. Such change is an event and may=20 >>>>>>>> have an impact on the overall communication. This can be told=20 >>>>>>>> directly to MN or HA. Direct communication to MN (if accepted=20 >>>>>>>> as >>>>>>>> benefit:-)) in such case will need standardization. >>>>>>>> Communication of this information to HA does not (I consider=20 >>>>>>>> this as a benefit). >>>>>>>> HA may act upon that event, and the rest you >>>>>>>> know: rules in reverse direction. >>>>>>>=20 >>>>>>> =3D> There is no need to _tell_ the MN anything. There are two=20 >>>>>>> issues here. >>>>>>> First, changing network conditions are best known e2e. So the MN = >>>>>>> will know that anyway based on the traffic running between it=20 >>>>>>> and the CN. >>>>>>> The other issue is related to cost for certain times of day.=20 >>>>>>> This is a routing issue in the HA and has nothing to do with=20 >>>>>>> which interface the MN selects. The selected CoA has zero impact = >>>>>>> on the HA's upstream selection. Completely irrelevant actually. >>>>>>> Of course, as far as cost on the visited link, the MN knows = best. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> - Access provider may set up different parameters for traffic=20 >>>>>>>> shaping for each of HA interfaces. These preferences may vary=20 >>>>>>>> independently of change of backbone provider but dependently on = >>>>>>>> the time of day. >>>>>>>> The rest you know, whether it changes somebodies opinion. >>>>>>>=20 >>>>>>> =3D> But again, this has zero effect on CoA selection. The two=20 >>>>>>> issues are completely orthogonal. Selecting CoA1 or CoA2 has=20 >>>>>>> zero impact on the HA's upstream route. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> - I presume that in RO mode this is similar to HA mode, and I'm = >>>>>>>> in when it comes to send rules in reverse direction between CN = and MN. >>>>>>>> Benefits of doing that is that any change percieved by CN as=20 >>>>>>>> important to react upon can be expressed in proposal of new = rules. >>>>>>>> The sources causing changes may include but not limited to, are = >>>>>>>> user, network managemnt events, application generated events, = etc. >>>>>>>>=20 >>>>>>>> So feel free to consider this as benefits or not >>>>>>>=20 >>>>>>> =3D> You seem to think that there is a relationship between=20 >>>>>>> upstream routing and CoA selection. That's not the case at all. >>>>>>> These are two different addresses from two different networks. >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>>=20 >>>>>>>> /yuri >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>> Sent: Wednesday, June 03, 2009 11:47 AM >>>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>> Cc: mext@ietf.org >>>>>>>> Subject: Re: [MEXT] Important considerations for directionality = >>>>>>>> of flowbindings >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 3/06/09 7:33 PM, "Yuri Ismailov" = wrote: >>>>>>>>=20 >>>>>>>>> Hesham, >>>>>>>>>=20 >>>>>>>>> Whenever we talk about sending additional information, the=20 >>>>>>>>> "waste of bandwidth" can be brought up. So I do not have an=20 >>>>>>>>> answer for that besides speculations around it. >>>>>>>>=20 >>>>>>>> =3D> no no, I don't mean it literally, I mean that the message=20 >>>>>>>> doesn't do anything, i.e. Has no benefit. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Speaking about benefits, everybody who knows the area is=20 >>>>>>>>> capable of turning things up side down. I assume it is=20 >>>>>>>>> subjective standpoint of considering things as benefits or=20 >>>>>>>>> disadvantages and all is about to agree or disagree. >>>>>>>>=20 >>>>>>>> =3D> That's fine, I'm asking for benefits in your opinion not=20 >>>>>>>> someone else's. >>>>>>>> It's impossible to discuss this if I can't see any benefits=20 >>>>>>>> because you didn't send any. What you sent were actions that=20 >>>>>>>> can be done by the HA and I responded by saying that the same=20 >>>>>>>> (or >>>>>>>> more) information is available to the MN. Therefore, if you=20 >>>>>>>> think there are additional benefits to doing this in the HA=20 >>>>>>>> then you need to tell us. >>>>>>>>=20 >>>>>>>> The bottom line is this: MIP works by letting the MN install=20 >>>>>>>> bindings in the HA. If you want things to work in reverse you=20 >>>>>>>> need to justify it. I can't see any justifications because=20 >>>>>>>> you're not answering my questions on your scenarios. So, count=20 >>>>>>>> me out on the reverse direction :). >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> For >>>>>>>>> me those I wrote about are benefits or potential benefits if = you want. >>>>>>>>=20 >>>>>>>> =3D> No you didn't. You wrote about things that can be done. = Many=20 >>>>>>>> things can be done by many entities, the question is why the HA = >>>>>>>> and not the MN. >>>>>>>>=20 >>>>>>>>> One important thing in the discussion, although mentioned, but = >>>>>>>>> forgotten later is that by making rules distribution one way=20 >>>>>>>>> only, we do create limitation for benefits, or potential=20 >>>>>>>>> benefits if this sounds better. >>>>>>>>=20 >>>>>>>> =3D> Well, we won't know what we're missing unless someone = tells us. >>>>>>>> So far no one has mentioned the advantages of doing things in=20 >>>>>>>> the reverse direction. >>>>>>>> There is always something missing from a protocol (it's=20 >>>>>>>> engineering), the question us whether it's significant or worth = >>>>>>>> the trouble. >>>>>>>>=20 >>>>>>>> Hesham >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> /yuri >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>> Sent: Wednesday, June 03, 2009 10:10 AM >>>>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>> Cc: mext@ietf.org >>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>> directionality of flowbindings >>>>>>>>>=20 >>>>>>>>> Yuri, >>>>>>>>>=20 >>>>>>>>> I can't parse those events you refer to. I'l answer both = emails here. >>>>>>>>> First the events you refer to: >>>>>>>>>=20 >>>>>>>>>>> - network condition towards CN(s) >>>>>>>>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>>>>>>>=20 >>>>>>>>> =3D> What's the event? A change in those conditions? The MN=20 >>>>>>>>> knows the conditions of the e2e path as well as or better than = the HA. >>>>>>>>> What is the benefit of having the HA send a hint and how=20 >>>>>>>>> reliable is that hint anyway? >>>>>>>>>=20 >>>>>>>>>>> - Access provider (any access, not necessarily wireless) who = >>>>>>>>>>> offeres HA services preferences change >>>>>>>>>=20 >>>>>>>>> =3D> Preferences change to what?? How does it know if such=20 >>>>>>>>> change works for the MN at all? This is way too vague to be=20 >>>>>>>>> able to discuss tradeoffs. >>>>>>>>>=20 >>>>>>>>>>> - Change of the access provider traffic to another backbone=20 >>>>>>>>>>> provider due to the time of the day. >>>>>>>>>>> - Traffic condition on HA interface, which accepts traffic=20 >>>>>>>>>>> from MN if MN sends on some particular local interface >>>>>>>>>=20 >>>>>>>>> =3D> These are path changes. The HA has _no idea_ how such a=20 >>>>>>>>> change affects each MN/CN combination and it's "hint" can=20 >>>>>>>>> cause more problems than it solves. BTW, if you're talking=20 >>>>>>>>> about hints then we're no longer talking about installing=20 >>>>>>>>> bindings in the MN. This is a different topic. MIP doesn't=20 >>>>>>>>> transfer hints, it pretty much sends "orders" >>>>>>>>> from one end to another. >>>>>>>>>=20 >>>>>>>>> Now to the actions required by the MN: >>>>>>>>>=20 >>>>>>>>>> - reject, >>>>>>>>>> - re-evaluate and reject >>>>>>>>>> - re-evaluate and accept >>>>>>>>>> - accept >>>>>>>>>=20 >>>>>>>>> =3D> First, by assuming that the MN can reject the "hint" as = you=20 >>>>>>>>> call it you invalidate the whole argument for the HA to = install rules. >>>>>>>>> Rejecting a hint or even evaluating it means that the MN knows = more. >>>>>>>>> Therefore, the HA's hint is a complete waste of bandwidth. >>>>>>>>>=20 >>>>>>>>> I'm still confused about the _benefits_ you see here. Or are=20 >>>>>>>>> you assuming that the MN can't know those hints without the=20 >>>>>>>>> HA's involvement? But if you're assuming that, then how can it = >>>>>>>>> reject the hints? This whole proposal makes no sense to me at=20 >>>>>>>>> all. Not to mention the complexity you implicitly assume in=20 >>>>>>>>> order to generate those, hopefully reliable, hints. >>>>>>>>>=20 >>>>>>>>> Hesham >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 3/06/09 5:23 PM, "Yuri Ismailov"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Hesham, >>>>>>>>>>=20 >>>>>>>>>> In my view these are events not scenarious. These events are=20 >>>>>>>>>> known by HA but not MN. If HA acts upon events, given that it = >>>>>>>>>> knows somewhat more about MN, not only IP addresses, it (HA)=20 >>>>>>>>>> can generate new rules and send them as hint to MN. Back=20 >>>>>>>>>> again, MN has four >>>>>>>>>> options: >>>>>>>>>>=20 >>>>>>>>>> The benefit will be obviously that the new rules (if=20 >>>>>>>>>> accepted) may llead to a better overall communication = characteristics. >>>>>>>>>>=20 >>>>>>>>>> /yuri >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> =3D> I'm trying to understand what you mean above. These are=20 >>>>>>>>>> all scenarios, the question is: What is the benefit for the=20 >>>>>>>>>> HA to transfer rules? The HA will not know the path between=20 >>>>>>>>>> the MN and CN more than either node does. So I don't=20 >>>>>>>>>> understand what _benefits_ you see here. >>>>>>>>>>=20 >>>>>>>>>> Hesham >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Pretty much sure that there are more examples and I=20 >>>>>>>>>>> encourage to think about those not from MN point of view but = >>>>>>>>>>> rather from the HA service provider. >>>>>>>>>>>=20 >>>>>>>>>>> /yuri >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>>>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>>>> Cc: mext@ietf.org >>>>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>>>> directionality of flowbindings >>>>>>>>>>>=20 >>>>>>>>>>> Yuri, >>>>>>>>>>>=20 >>>>>>>>>>> It is just rules TRANSFER which is the matter of MIP. So=20 >>>>>>>>>>> where >>>>>>>>>>>> is the logic when saying that MN to HA rules transfer is a=20 >>>>>>>>>>>> practical engineering and HA to MN is an academic interest? >>>>>>>>>>>=20 >>>>>>>>>>> =3D> I think we've (I'm including myself) highlighted = several=20 >>>>>>>>>>> reasons for why it makes little sense to transfer rules from = >>>>>>>>>>> HA to MN. >>>>>>>>>>> Instead of rat-holing on theory Vs practice, you (or others=20 >>>>>>>>>>> advocating the other direction) need to come up with reasons = >>>>>>>>>>> for doing things this way. This way we can think like=20 >>>>>>>>>>> engineers about tradeoffs. >>>>>>>>>>> Absent that, I don't see any point in having theory Vs=20 >>>>>>>>>>> practice high level discussions, which will lead nowhere. >>>>>>>>>>>=20 >>>>>>>>>>> Hesham >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards >>>>>>>>>>>> Yuri >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>>>>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>>>>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>>>>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>>>>> directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi Pierrick, >>>>>>>>>>>>=20 >>>>>>>>>>>> On Jun 2, 2009, at 4:11 PM,=20 >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>> Please see inline comment. >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>> Pierrick >>>>>>>>>>>>=20 >>>>>>>>>>>> ________________________________________ >>>>>>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>>> De la part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 = 09:35 =C0 : >>>>>>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important=20 >>>>>>>>>>>> considerations for directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham, >>>>>>>>>>>> This is nice story and makes some sense for the discssion,=20 >>>>>>>>>>>> however some details are ommited. In your adventure with=20 >>>>>>>>>>>> the helpdesk, it (the >>>>>>>>>>>> helpdesk) is a third party service and thus your=20 >>>>>>>>>>>> conclusions make sence. >>>>>>>>>>>> Think of the situation when superior of a heldesk person=20 >>>>>>>>>>>> will tell him/her to check access point in some room. Would = >>>>>>>>>>>> it be the same reaction? I assume not. By that I mean that=20 >>>>>>>>>>>> if, for example, I'll install home agent in my home=20 >>>>>>>>>>>> network, I can make it know anything I want about MN, and=20 >>>>>>>>>>>> more intresting is that how I will do it, does not require=20 >>>>>>>>>>>> any standardization. >>>>>>>>>>>> In other words, I'm superior of my HA. >>>>>>>>>>>> This situation is not unthinkable, I personally believe=20 >>>>>>>>>>>> that this is much more efficient way of using HA=20 >>>>>>>>>>>> fnctionality as opposed to big service providers who will=20 >>>>>>>>>>>> have to fight with scalability and performance. >>>>>>>>>>>> However, one does not exclude another. >>>>>>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> The difference between policy and rules is not only a=20 >>>>>>>>>>>> matter of conversion. A policy, is a static, or=20 >>>>>>>>>>>> quasi-static, set of guidance for the MN (e.g use access=20 >>>>>>>>>>>> network X for application type >>>>>>>>>>>> A,...) while a rule update requires to be more dynamic. I = mean: >>>>>>>>>>>> eventually a policy could be updated depending on network=20 >>>>>>>>>>>> condition (e.g if X overloaded, use access network Y for=20 >>>>>>>>>>>> application type A,...) but a rule reacts on local triggers = (e.g. >>>>>>>>>>>> modification of the radio link >>>>>>>>>>>> quality) with a shorter period of variation. So, IMHO,=20 >>>>>>>>>>>> there is no requirement for updating policy on a short=20 >>>>>>>>>>>> period and out-of-band mechanism can be used (e.g. IEEE >>>>>>>>>>>> 802.21 in push mode,...). >>>>>>>>>>>>=20 >>>>>>>>>>>> Fully agree! >>>>>>>>>>>> This is why I do not support the exchange of rules from the = >>>>>>>>>>>> HA to the MN. >>>>>>>>>>>> Policies may be exchanged from the HA to the MN, but MIP is = >>>>>>>>>>>> definitely not the protocol to transport them. >>>>>>>>>>>>=20 >>>>>>>>>>>> Nicolas >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> My 2 cents... >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Is there any reason to restrict where such convertion takes = place? >>>>>>>>>>>> True >>>>>>>>>>>> that a HA does not know what is going on in the access=20 >>>>>>>>>>>> network, on the other hand HA may know what is the network=20 >>>>>>>>>>>> condition between HA and correspondent node. Either of this = >>>>>>>>>>>> information is important, if not equally important. >>>>>>>>>>>> It is not really difficult to let an MN to reject rules=20 >>>>>>>>>>>> sent by HA, which in my view would be quite natural. This=20 >>>>>>>>>>>> implies that HA must follow the rules installed by MN until = >>>>>>>>>>>> explicit acceptance has been received from MN. >>>>>>>>>>>> Such procedure is very similar to an MN beahviour when=20 >>>>>>>>>>>> initiating new BU, where MN is not supposed to send any=20 >>>>>>>>>>>> traffic before BU confirmation. >>>>>>>>>>>> BTW, what is the numerical representation of "rough = consensus"? >>>>>>>>>>>> I assume is when majority is for, is it so? >>>>>>>>>>>> Yuri >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>>> On Behalf Of Hesham Soliman >>>>>>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>>>>>> To: mext >>>>>>>>>>>> Subject: [MEXT] Important considerations for directionality = >>>>>>>>>>>> of flow bindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>> I've always been a fan of the IETF's tradition of rough=20 >>>>>>>>>>>> concensus (as opposed to voting). To me, this implies that=20 >>>>>>>>>>>> you need to get your point across and get other people to=20 >>>>>>>>>>>> see that point of view. >>>>>>>>>>>> As opposed to other organisations that require their=20 >>>>>>>>>>>> members to vote and end up with rigid political positions. >>>>>>>>>>>>=20 >>>>>>>>>>>> The chairs asked us about the directionality question of=20 >>>>>>>>>>>> the flows bindings. >>>>>>>>>>>> On the charter question, I said that the charter doesn't=20 >>>>>>>>>>>> need to mention how a solution should work, but rather what = >>>>>>>>>>>> problem needs to be solved. >>>>>>>>>>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>>>>>>>>>> transferring rules "between" the MN and HA without=20 >>>>>>>>>>>> mentioning directions. >>>>>>>>>>>>=20 >>>>>>>>>>>> Nevertheless, we still need to agree on identifying the=20 >>>>>>>>>>>> requirement for the solution. And when it comes to this,=20 >>>>>>>>>>>> I'm strongly against voting and I'll practice this by=20 >>>>>>>>>>>> explaining in this email why I think rules can not be=20 >>>>>>>>>>>> transferred from the HA to the MN and that the only=20 >>>>>>>>>>>> direction that makes sense in MIP is >>>>>>>>>>>> MN->HA. I'll deliberately ignore arguments like "some=20 >>>>>>>>>>>> MN->people want >>>>>>>>>>>> this" or "an SDO wants this". They fall under the=20 >>>>>>>>>>>> "meaningless words" >>>>>>>>>>>> category and I'm incapable of discussing them because they=20 >>>>>>>>>>>> come with voting attitudes. They all need to be justified=20 >>>>>>>>>>>> if the WG wants to have a technical _discussion_. >>>>>>>>>>>>=20 >>>>>>>>>>>> Here are my reasons: >>>>>>>>>>>>=20 >>>>>>>>>>>> 1. The HA does not know whether a CoA is tied to a certain=20 >>>>>>>>>>>> access technology. It is one thing for the HA to send a=20 >>>>>>>>>>>> message saying "forward port 80 traffic on a wifi link" (a >>>>>>>>>>>> policy) and a completely different thing to say "forward=20 >>>>>>>>>>>> port 80 traffic using CoA 3ffe::1" >>>>>>>>>>>> (a rule). >>>>>>>>>>>>=20 >>>>>>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem = now? >>>>>>>>>>>> The problem is that the HA has no idea about dynamic=20 >>>>>>>>>>>> changes on that wifi link. It doesn't know if it's=20 >>>>>>>>>>>> congested, it doesn't know what application is using port=20 >>>>>>>>>>>> 80 (it doesn't have to be web >>>>>>>>>>>> traffic) or port 8000 for that matter and doesn't even know = >>>>>>>>>>>> if the AP of that wifi link works at all. >>>>>>>>>>>> Finally, it >>>>>>>>>>>> doesn't know the user's policies or other admin policies=20 >>>>>>>>>>>> for that MN. >>>>>>>>>>>> This type of information needs to be sent regularly because = >>>>>>>>>>>> it changes all the time and requires serious cross layer=20 >>>>>>>>>>>> integration including sometimes layer 8 integration! It's=20 >>>>>>>>>>>> completely impractical. >>>>>>>>>>>>=20 >>>>>>>>>>>> 3. If the HA installed rules in the MN, what happens if the = >>>>>>>>>>>> MN wants to change those rules. Say the wifi link went=20 >>>>>>>>>>>> down, or the MN's wifi interface went down and it wants to=20 >>>>>>>>>>>> move that traffic to another interface. Would the HA reject = >>>>>>>>>>>> such move? >>>>>>>>>>>> Does the MN have to justify to the HA why it needs to move=20 >>>>>>>>>>>> traffic? Does that involve writing a letter perhaps? >>>>>>>>>>>> If you say "well in that case, the HA should let the MN=20 >>>>>>>>>>>> move the traffic" >>>>>>>>>>>> then I'll ask you: what's the point of having the HA=20 >>>>>>>>>>>> install this stuff if it has no authority and how does it=20 >>>>>>>>>>>> know the reason for the MN's movement of the flow? >>>>>>>>>>>> The way to control how users do things is to incentivise=20 >>>>>>>>>>>> them with charging models and show them that things work=20 >>>>>>>>>>>> better on certain technologies, not by installing rules=20 >>>>>>>>>>>> that can't be followed. It's a broken mindset and we've=20 >>>>>>>>>>>> known that it's broken for a long time. >>>>>>>>>>>>=20 >>>>>>>>>>>> 4. Some people mentioned that the HA should be able to=20 >>>>>>>>>>>> revoke flows on the MN. I'm perfectly fine with that, just=20 >>>>>>>>>>>> extend the binding revocation draft to handle flows and the = >>>>>>>>>>>> rest is pretty straight forward. >>>>>>>>>>>>=20 >>>>>>>>>>>> Finally, I'll indulge in a true story that happened to me a = >>>>>>>>>>>> few years ago when I found that my wifi link wasn't working = >>>>>>>>>>>> in a hotel (no >>>>>>>>>>>> radio) >>>>>>>>>>>> and called the help desk. He insisted that the link was up=20 >>>>>>>>>>>> an I insisted that it wasn't. When I asked him to tell me=20 >>>>>>>>>>>> how he knows the link is up he said: I can ping the AP! Of=20 >>>>>>>>>>>> course after another >>>>>>>>>>>> 5 minutes of trying to convince him that pinging the AP=20 >>>>>>>>>>>> doesn't mean the radio is actually working he sent someone=20 >>>>>>>>>>>> to the hotel who in turn realised that the radio was not = working. >>>>>>>>>>>> For those people who want rules to be transferred from the=20 >>>>>>>>>>>> HA to the MN, please think of your HA as this help desk=20 >>>>>>>>>>>> person, i.e. >>>>>>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>>>>>=20 >>>>>>>>>>>> I hope this helps with the realisation that decisions can't = >>>>>>>>>>>> be made here based on voting and that there is little merit = >>>>>>>>>>>> to transferring rules from the HA to the MN. Policies can=20 >>>>>>>>>>>> be transferred without any problems, but not rules. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From hesham@elevatemobile.com Tue Jun 9 00:38:48 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7FF3A6E1E for ; Tue, 9 Jun 2009 00:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 Af9z1ceWov5f for ; Tue, 9 Jun 2009 00:38:44 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 0A8703A6DEA for ; Tue, 9 Jun 2009 00:38:43 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MDvuj-0003e4-Sj; Tue, 09 Jun 2009 17:38:37 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 09 Jun 2009 17:38:21 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 07:38:48 -0000 On 9/06/09 5:07 PM, "Yuri Ismailov" wrote: > Hesham, below is my attempt to understand what the following means (not a= n > easy task though) >=20 > =20 >> =3D> So now that we agree that we are only talking about CoAs then I don't= see >> any meaningful information coming from the HA. Hints about upstream >> routing changes ...etc are relevant to HoA selection (even if the HoA is= not >> tied to a physical interface it doesn't matter). This is an >> interesting problem to discuss but I want to be clear on its context. So= to >> summarise my opinion: >> HA-> MN hints (not rules) may be relevant for intial HoA selection for >> certain connections. The types of hints and how to formulate this in a g= lobal >> manner can lead to interesting work (although it's a complex >> problem). However, this information is not in anyway relevant to CoA/phy= sical >> interface selection on the MN. >=20 > First, is that we have agreed already that we are talking about interface= s. > Yes, we are talking about interfaces configured with CoA. Interfaces > configured with HoA does not give any information about characteristices = of > interfaces configured with CoA, thus choosing HoA or HA can not provide a= ny > meaningful information about access characteristics. Thus it is not clear= at > all where from comes idea about relevance to HA selection. =3D> The hints that you were suggesting that the HA sends are only relevant t= o HoA selection. Do you agree? > In all my examples (e.g. the latest one about broadband operators) it doe= s not > matter which HA (HoA) is used. All what matters is which access MN uses a= nd if > there was traffic shaping policy applied to that access by an access prov= ider. > We have agreed that MN can not know about the later. HA can. =3D> No! You were talking about traffic shaping by the HA or its upstream ISP= . What do you mean by "provider" above? Where is the traffic being impacted? >=20 > Second, is that we are talking about sending rules from HA to MN. I call = these > rules hints, because and only because in my view MN should have rights to > ignore the rules from HA. Both transportwise and contentwise, we are stil= l > talking about rules. At the moment I do not see any specific need for spe= cific > types of hints. =3D> If we're talking about CoA selection I don't see any relevance to those hints. The only way you can show there is relevance is by providing an example. The example you provided had no relevance to CoA selection. I don'= t understand why we need to go back two emails again. If you still think your scenario had relevance to CoA selection then please respond to my earlier response to your scenario. >=20 > Information about the fact that up/down link from/to HA for a particular > interface was downgraded is very relevant for MN because based on this > information MN can select another interface for some of its flows and mak= e > correspondent move. =3D> Are you saying the MN will notify the HA everytime I do this: Ifdown eth1: ifup eth1 Why on earth would you do that? If this is not the case then what is the objactive of > interfaces selection? If better choice of interface for applications is n= ot an > objective then why bother about flow mobility at all? =3D> I don't understand what you're saying Yuri. Please respond to my earlier email which responded to your scenario. I can't see how you still think tha= t the HA can influence CoA selection. Hesham >=20 > Regards > Yuri >=20 >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Monday, June 08, 2009 4:29 PM > To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of > flowbindings >=20 >=20 >=20 >=20 > On 9/06/09 12:12 AM, "Yuri Ismailov" wrote: >=20 >> =20 >> =3D> Yes but I still think you're talking about something else. The >> interface you're talking about seems to be associated with the HoA. >> This is the only case where I can see the relevance of HA hints (not >> rules). The interfaces I'm talking about and discussed in the context >> of flow bindings are those associated with CoAs. There is nothing >> coming from the HA about its links ...etc that can have any impact on Co= A >> selection. >>=20 >> Hesham >> here I tend to agree. I actually ment interfaces with CoA, but now >> realized that in such configuration, where each of interfaces has it's >> own HA configured, it is most likely that each of interfaces will have >> different HoA. >> Once this is the case then moving a flow between those interfaces will >> lead to change of HoA. As we are in MIP context, I would better avoid >> that. In the whole discussion I mean interafces with CoA because >> selection of HoA and/or associated to it interface can not be based on >> physical characteristics of that interface. >=20 > =3D> Sounds fine to me. >=20 >>=20 >> So the valid and meaningful scenario is moving flow(s) between >> interfaces associated with the same HA, whether all interfaces of the >> MN or some of them will be configured this way does not really matter. >>=20 >> Fine with me. Should we finalize then? As I see it, once there is a >> meaningful information, which can be sent in HA -> MN direction, then >> MN can use it for re-evaluting policies and producing the new set of >> rules. Definetely not at all times new rules will be produced, they >> may stay unchanged, as it will be the case with many other events taking >> place at either side: MN or HA. >>=20 >> Is that correct? >=20 > =3D> So now that we agree that we are only talking about CoAs then I don't = see > any meaningful information coming from the HA. Hints about upstream routi= ng > changes ...etc are relevant to HoA selection (even if the HoA is not tied= to a > physical interface it doesn't matter). This is an interesting problem to > discuss but I want to be clear on its context. So to summarise my opinion= : > HA-> MN hints (not rules) may be relevant for intial HoA selection for > certain connections. The types of hints and how to formulate this in a gl= obal > manner can lead to interesting work (although it's a complex problem). > However, this information is not in anyway relevant to CoA/physical inter= face > selection on the MN. >=20 > Hesham >=20 >=20 >>=20 >> Regards >> Yuri >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Monday, June 08, 2009 2:00 PM >> To: Yuri Ismailov; Nicolas Montavont; >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of >> flowbindings >>=20 >> Yuri, >>=20 >> I think we're getting close here. >>=20 >>=20 >> On 8/06/09 6:29 PM, "Yuri Ismailov" wrote: >>=20 >>> Hesham, It looks like that the only point of disagreement is about >>> changing HA and mapping between HA and access. >>> Some explanations of what I mean below: >>>=20 >>>=20 >>> 1. Changing HA. >>> As it follows from group charter change of HA is in the plans of MEXT >>> WG. I assume that this is going to be a separate work item because >>> the reason specified for that is very specific and relates to >>> deployment more than to flow mobility. Do not want to speculate, >>> about this right now but the change of HA does not necessarily means ch= ange >>> of rules. >>> So the proposal is to not to discuss change of HA as you suggested. >>=20 >> =3D> Agreed. >>=20 >>>=20 >>> 2. In my example I do not mean change of HA as an explicit procedure >>> specified separately. One confirmation to that is that single HA for >>> all interfaces is included and valid option. Based on the HA -> MN >>> exchange, the MN may perform interface selection procedure and may >>> choose another interface for some flow(s). In multiple HA case it >>> will result of the rules update MN -> HA to the HA which is relevant >>> for the new interface chosen for flows. Please notice, There is >>> nothing about HA change, only about interface selection. >>=20 >> =3D> Yes but I still think you're talking about something else. The >> interface you're talking about seems to be associated with the HoA. >> This is the only case where I can see the relevance of HA hints (not >> rules). The interfaces I'm talking about and discussed in the context >> of flow bindings are those associated with CoAs. There is nothing >> coming from the HA about its links ...etc that can have any impact on Co= A >> selection. >>=20 >>>=20 >>> 3. I do not map HA and access. It is allowed for any access provider >>> to offer HA service and once this is the case it will be so. Thus an >>> MN can have multiple HA configured for the use on different interfaces. >>=20 >> =3D> Good, we agree on that too. >>=20 >> Hesham >>=20 >>>=20 >>> Regards >>> Yuri >>>=20 >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Friday, June 05, 2009 4:18 PM >>> To: Yuri Ismailov; Nicolas Montavont; >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of >>> flowbindings >>>=20 >>>=20 >>>=20 >>>> First is that I assume that we have simulteneous multiaccess in >>>> mind, i.e. MN has more than one interface to choose from for its >>>> flows. If this is not the case then I will stop the discussion. This >>>> assumption is based on the fact that we are (I hope at least) discussi= ng >>>> flow mobility. >>>=20 >>> =3D> Sure. >>>=20 >>>>=20 >>>> Secondly, I consider that MN chooses an interface but not CoA. I >>>> gave a though about that and did not come up with any information >>>> which can be derived from CoA in order to choose it. An interface >>>> has at least expected characteristics, thus can be a subject of >>>> choice. Any clarification about that would be appreciated. >>> =3D> An application would choose an interface, but of course the IP >>> stack selects the corresponding address. I'm sure there is no >>> disagreement there. >>>=20 >>>>=20 >>>> Next assumptions are about possible configurations of HA >>>> - Single HA for all interfaces configured in the mobile. HA can >>>> belong to any of the access providers of each of access technology >>>> used by MN. >>>=20 >>> =3D> Ok. >>>=20 >>>>=20 >>>> - One HA per access or set of accesses, which is subset of all >>>> access techologies presented or potentially may be presented >>>> (detached >>>> devices) in MN. >>>=20 >>> =3D> Now you're getting into a different problem space from flow mobility= . >>> This is why I wanted you to break the scenario down. We are not >>> dealing with multiple HoAs in this work item, we're dealing with >>> multiple CoAs, i.e. One HoA. >>>=20 >>>> Anticipating numerous questions about that can say that I looked at >>>> such configuration and did not find anything strange with it, i.e. >>>> (1) it works, >>>> (2) it does not require any change to MIP or any other of its >>>> extensions. (3) Configuration is performed per interface and does >>>> not introduce any ambiguities. (4) it is natural for access provider >>>> to offer HA service. >>>=20 >>> =3D> Yes of course it works but as I read this I'm guessing that you >>> want the MN to change HoA. This is not the problem we're discussing >>> in this WG. >>> Another issue, I'm not comfortable with the wording of "HA per access" >>> because they're not tied to access. Let's just say there are multiple >>> Has and not associate it with an access. >>>=20 >>>>=20 >>>> - "Residential" HA. Assumption is that it can be either one of HA's >>>> or a single HA for all types of accesses. This is the matter of MN >>>> configuration. >>>> "Residential". >>>=20 >>> =3D> Please don't tie HA to access. >>>=20 >>>>=20 >>>> - Any HA may have multiple interfaces, e.g. "residential" HA may be >>>> connected to mobile broadband, DSL, etc. >>>=20 >>> =3D> sure >>>=20 >>>>=20 >>>> Next assumption comes from the example (e.g. latest one) >>>> - Traffic shaping is applied in both directions (up/down) link (in >>>> practice this is the case). >>>> - Traffic shaping (TS) is applied to user subscription. In other >>>> words TS is applied to packets belonging to a particular >>>> subscription but not to an aggregated traffic on gateway interfaces. >>>> HA is not necessary (however, nothing prevents from that) a gateway >>>> where TS is applied. >>>>=20 >>>>=20 >>>> I hope that I have not missed something, although it may be possible. >>>> If we can agree on that or correct if something is wrong here and >>>> agree later then we know how to proceed further on >>>=20 >>> =3D> Your scenario is fine (with the wording changes for tying Has to acc= ess). >>> But I want to pre-empt any suggestion that the HA will tell the MN to >>> use a different HoA. This is very possible but it's not the problem >>> being discussed here. It may well be something for charter discussion >>> but it has zero impact on flow bindings for multiple CoAs. >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> /yuri >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Friday, June 05, 2009 11:37 AM >>>> To: Yuri Ismailov; Nicolas Montavont; >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of >>>> flowbindings >>>>=20 >>>> Yuri, >>>>=20 >>>>=20 >>>>> Still not clear for me why you call scenarious invalid? >>>>> Some broadband providers (this is used in practice) have quota on >>>>> the amount of traffic sent by users. Once quota is exceeded >>>>> provider downgardes outgoing traffic from its network to 64Kbs >>>>> (this figure is the real example from real provider). Such >>>>> combination of to paths, where one is high speed, lets say 10 Mbs >>>>> and another one is 64Kbs is quite crusual to apps running on top of T= CP. >>>>> Not for all types of traffic though. >>>>=20 >>>> =3D> Yes I know the scenario but I keep saying to you that the change >>>> in upstream routing in the HA has nothing to do with CoA selection >>>> by the MN in the visited network. If anything, you want the MN to >>>> change it's HoA depending on how the switch to another upstream ISP wo= rks. >>>> It's a completely irrelevant issue to this discussion. Do you agree? >>>> If not why not? I really want to see an answer to this point. >>>>=20 >>>> =20 >>>>=20 >>>>=20 >>>>>=20 >>>>> MN can not know about this situation. Nobody will send this >>>>> information to MN. >>>>=20 >>>> =3D> Yes and if it knows what will it do??? If you can answer that you >>>> will fix the deadlock we have. >>>>=20 >>>>> That means that MN will choose its interfaces based on its >>>>> knowledge about 10Mbs link capabilities. >>>>=20 >>>> =3D> You're talking about two different things. The MN doesn't choose >>>> the HA's outgoing interface! What am I missing? >>>>=20 >>>> Obtaining this isnformation from HA is quite >>>>> significant to make a better decision about choice of interfaces >>>>> for its flows. >>>>> This is concrete example of what happens in the reality. >>>>> Do you consider that this information will be useless for MN? >>>>=20 >>>> =3D> Completely useless. Unless I'm missing something in your scenario. >>>> Just write down step by step what will happen and include messages. >>>> I don't see how this can possibly be relevant to the MN. >>>>=20 >>>> Hesham >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> /yuri >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: Thursday, June 04, 2009 4:38 PM >>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>> pierrick.seite@orange-ftgroup.com >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of >>>>> flowbindings >>>>>=20 >>>>> Yuri, >>>>>=20 >>>>>=20 >>>>> On 5/06/09 12:01 AM, "Yuri Ismailov" wro= te: >>>>>=20 >>>>>> Hesham, >>>>>>=20 >>>>>> I provided several scenarious which you said are invalid. This is >>>>>> where my conclusion about standpoint comes from. >>>>>> Whether you call hints policies or rules it does not change what >>>>>> information can be provided by HA to MN. >>>>>=20 >>>>> =3D> It changes the outcome for the work item we're discussing. I'm >>>>> trying to come to a conclusion on this and there is a huge >>>>> difference between transferring policies and installing flow bindings= . >>>>>=20 >>>>>> By sending rules HA does not install anything in MN. Likewise, MN >>>>>> does not install rules in HA, it informs HA about currently made cho= ices. >>>>>> As I remember rules will not be valid until proper Ack arrival, >>>>>> which for me means that may not be instantiated at all. >>>>>> Niether rules nor polices are specific to MIP. As I wrote those >>>>>> can be exchanged between hosts without any MIP implementation, >>>>>> just for access selection purposes. Once it was decided to make it >>>>>> as part of MIP protocol, I'm fine with that. Do not have any idea >>>>>> to discuss this, while personally consider that the work on rules >>>>>> transfer can very well fit into the MEXT group but as a separate >>>>>> work item, but this is not the case now, so good enough the way it i= s. >>>>>> And back again, it really gets repeated, so will lead to nowhere, >>>>>> you've got my arguments and tell that the information, which I'm >>>>>> talking about, is not usefull. What can I say more? I can put you >>>>>> on my position and start asking questions instead of answering. >>>>>> So, why it is not usefull? >>>>>=20 >>>>> =3D> I explained why the specific information you mentioned was not >>>>> useful/useable by the MN and this is what I referred to as unanswered= . >>>>> Because if you agree with my previous explanations then we don't >>>>> need to discuss it further. If you disagree you certainly didn't >>>>> tell me why. You have the charge of proof because you want to >>>>> change the way MIP works currently, that's all I'm trying to say. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>>=20 >>>>>> /yuri >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>> Sent: Thursday, June 04, 2009 4:00 AM >>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>> pierrick.seite@orange-ftgroup.com >>>>>> Cc: mext@ietf.org >>>>>> Subject: Re: [MEXT] Important considerations for directionality of >>>>>> flowbindings >>>>>>=20 >>>>>> Yuri, >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Missing is additional information which may be helpful in making >>>>>>> better decision about interface selection by MN. >>>>>>> Which information is that I wrote in my previous emails. Back to >>>>>>> my examples (not all, do not want to repeat myself). If HA will >>>>>>> have changed traffic shaping parameters on one of the incoming or >>>>>>> outgoing interfaces, this will be important information for MN to k= now. >>>>>>> We have agreed already that whether this information important or >>>>>>> not, benfitial or not is a matter of standpoint. >>>>>>=20 >>>>>> =3D> I don't agree or like to think that it's a matter of standpoint. >>>>>> That's why I asked you on every point you raised and compared this >>>>>> to the MN's knowledge on e2e basis. Once we have "standpoints" >>>>>> then we're getting outside the technical realm. The reason I don't >>>>>> think it's useful is that this information cannot be used by the >>>>>> MN to select a CoA. I've already stated that before and you seemed >>>>>> to agree so I don't know why you repeat this as a reason for the >>>>>> HA to install filters in the MN. Let me say it >>>>>> again: There is no correlation between the routing on the HA's >>>>>> upstream interfaces/ISP with the MN's selection of a CoA. >>>>>>=20 >>>>>>> I consider that knowing more is a benefit and will help to get >>>>>>> better result. >>>>>>>=20 >>>>>>> My point is still the same. I see the reverse rules sending as >>>>>>> possibility to provide more information to the MN, thus make MN >>>>>>> to get to better decision about interface selection for its flows. >>>>>>> This point has not changed since the beginning of the discussion. >>>>>>=20 >>>>>> =3D> This is why we're not making progress IMO: >>>>>>=20 >>>>>> 1. The hints you refer to are not the same things as installing >>>>>> rules on the MN. Completely different information in fact. You've >>>>>> essentially proved that when you suggested that the MN can accept >>>>>> or reject them. So, let's not call them rules. The more direct >>>>>> word for what you want to send is policies >>>>>>=20 >>>>>> 2. You didn't provide a valid scenario that we can discuss as to >>>>>> why it's needed or how it could work. I've asked numerous >>>>>> questions in each email that were not answered (with the exception >>>>>> of the last email). It's not possible to progress the discussion >>>>>> without answering each others' >>>>>> questions. You can go back through the threads and verify this. >>>>>>=20 >>>>>> 3. If we're sending rules from the HA to the MN and the MN can >>>>>> reject those rules then the whole exercise is pointless. You >>>>>> really want to send policies not rules. I can imagine those >>>>>> policies being one of the inputs that the MN uses to make a >>>>>> decision. I still fail to see how anything happening on the HA's >>>>>> upstream interfaces/ISP link can possibly influence the MN's decisio= n for >>>>>> CoA selection. >>>>>> This is another unanswered question. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>>=20 >>>>>>> /yuri >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>> Sent: Wednesday, June 03, 2009 4:09 PM >>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>> Cc: mext@ietf.org >>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>> of flowbindings >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 3/06/09 10:47 PM, "Yuri Ismailov" w= rote: >>>>>>>=20 >>>>>>>> Ok, see your point, however:-) >>>>>>>>=20 >>>>>>>> The major difference here is that your are talking about CoA >>>>>>>> selection and I'm talking about interface selection. Quite a big >>>>>>>> difference. >>>>>>>=20 >>>>>>> =3D> No, that's not the point really. The point is that there is no >>>>>>> relationship between CoA/interface selection on the MN and the >>>>>>> upstream ISP for the home network. >>>>>>>=20 >>>>>>>> I do not see any grounds for MN to select CoA, based on what? >>>>>>>> Prefix length? >>>>>>>> While selection of an interface is based on expected >>>>>>>> characteristics of the communication. Routes (up/down)link in my >>>>>>>> opinion do have impact on the characteristics and this is >>>>>>>> exactly the information missing in the MN when selecting interface= . >>>>>>>=20 >>>>>>> =3D> There is nothing missing for the MN to make this selection. >>>>>>> Please tell us specifically what is missing. You're changing >>>>>>> points on me all the time now. >>>>>>> Lets stick to one point at a time. What's missing? >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Whenever, MN decides to move a flow, the reason can be anything >>>>>>>> but not which CoA it has configured on each interface. >>>>>>>>=20 >>>>>>>> Another thing is that MN will notice something e2e if and only >>>>>>>> if such support is implemented in the MN. >>>>>>>=20 >>>>>>> =3D> Of course, so what? >>>>>>>=20 >>>>>>> Moreover, this notice can not be made at IP layer. >>>>>>>> TCP fights alone with all problems and never tells to any other >>>>>>>> layer what is going on. So what is left? Two options. Add this >>>>>>>> support to operating system, which makes its (support) existence >>>>>>>> questionable, or to applications, which is even more questionable. >>>>>>>=20 >>>>>>> =3D> It's interesting that you think it's questionable to add the >>>>>>> support to the MN's OS but not questionable to add the support to >>>>>>> the HA's OS, which will not lead to the same reliability as if it >>>>>>> were done in the MN. It doesn't make sense to me. >>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Well, that's debatable, but this is clearly not a reason to do >>>>>>>>>> anything. >>>>>>>>>>=20 >>>>>>>> Are you serious about that MIP may be broken because of that? >>>>>>>=20 >>>>>>> =3D> Yes! It's not designed to do what you want to do. Luckily, in >>>>>>> this case what you want, IMO, is broken anyway so it's not a proble= m. >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>>=20 >>>>>>>> /yuri >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>> Sent: Wednesday, June 03, 2009 1:15 PM >>>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>> Cc: mext@ietf.org >>>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>>> of flowbindings >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Still some answers, despite knowing that in your opinion they >>>>>>>>> are not benefits. >>>>>>>>>=20 >>>>>>>>> First of all MIP will not be breaked if the rules will be sent >>>>>>>>> in both directions. >>>>>>>>=20 >>>>>>>> =3D> Well, that's debatable, but this is clearly not a reason to >>>>>>>> do anything. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> - Access provider preferences relate to the use of backbone >>>>>>>>> provider, which may vary with the time of day. Changing >>>>>>>>> backbone provider can make quite big difference for >>>>>>>>> commnication between HA (if HA service is provided by the same ac= cess >>>>>>>>> provider) and CN(s). >>>>>>>>> The difference can be expressed in, let's say, number of hops, >>>>>>>>> load, possibly something else. Such change is an event and may >>>>>>>>> have an impact on the overall communication. This can be told >>>>>>>>> directly to MN or HA. Direct communication to MN (if accepted >>>>>>>>> as >>>>>>>>> benefit:-)) in such case will need standardization. >>>>>>>>> Communication of this information to HA does not (I consider >>>>>>>>> this as a benefit). >>>>>>>>> HA may act upon that event, and the rest you >>>>>>>>> know: rules in reverse direction. >>>>>>>>=20 >>>>>>>> =3D> There is no need to _tell_ the MN anything. There are two >>>>>>>> issues here. >>>>>>>> First, changing network conditions are best known e2e. So the MN >>>>>>>> will know that anyway based on the traffic running between it >>>>>>>> and the CN. >>>>>>>> The other issue is related to cost for certain times of day. >>>>>>>> This is a routing issue in the HA and has nothing to do with >>>>>>>> which interface the MN selects. The selected CoA has zero impact >>>>>>>> on the HA's upstream selection. Completely irrelevant actually. >>>>>>>> Of course, as far as cost on the visited link, the MN knows best. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> - Access provider may set up different parameters for traffic >>>>>>>>> shaping for each of HA interfaces. These preferences may vary >>>>>>>>> independently of change of backbone provider but dependently on >>>>>>>>> the time of day. >>>>>>>>> The rest you know, whether it changes somebodies opinion. >>>>>>>>=20 >>>>>>>> =3D> But again, this has zero effect on CoA selection. The two >>>>>>>> issues are completely orthogonal. Selecting CoA1 or CoA2 has >>>>>>>> zero impact on the HA's upstream route. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> - I presume that in RO mode this is similar to HA mode, and I'm >>>>>>>>> in when it comes to send rules in reverse direction between CN an= d MN. >>>>>>>>> Benefits of doing that is that any change percieved by CN as >>>>>>>>> important to react upon can be expressed in proposal of new rules= . >>>>>>>>> The sources causing changes may include but not limited to, are >>>>>>>>> user, network managemnt events, application generated events, etc= . >>>>>>>>>=20 >>>>>>>>> So feel free to consider this as benefits or not >>>>>>>>=20 >>>>>>>> =3D> You seem to think that there is a relationship between >>>>>>>> upstream routing and CoA selection. That's not the case at all. >>>>>>>> These are two different addresses from two different networks. >>>>>>>>=20 >>>>>>>> Hesham >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> /yuri >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>> Sent: Wednesday, June 03, 2009 11:47 AM >>>>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>> Cc: mext@ietf.org >>>>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>>>> of flowbindings >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 3/06/09 7:33 PM, "Yuri Ismailov" >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Hesham, >>>>>>>>>>=20 >>>>>>>>>> Whenever we talk about sending additional information, the >>>>>>>>>> "waste of bandwidth" can be brought up. So I do not have an >>>>>>>>>> answer for that besides speculations around it. >>>>>>>>>=20 >>>>>>>>> =3D> no no, I don't mean it literally, I mean that the message >>>>>>>>> doesn't do anything, i.e. Has no benefit. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Speaking about benefits, everybody who knows the area is >>>>>>>>>> capable of turning things up side down. I assume it is >>>>>>>>>> subjective standpoint of considering things as benefits or >>>>>>>>>> disadvantages and all is about to agree or disagree. >>>>>>>>>=20 >>>>>>>>> =3D> That's fine, I'm asking for benefits in your opinion not >>>>>>>>> someone else's. >>>>>>>>> It's impossible to discuss this if I can't see any benefits >>>>>>>>> because you didn't send any. What you sent were actions that >>>>>>>>> can be done by the HA and I responded by saying that the same >>>>>>>>> (or >>>>>>>>> more) information is available to the MN. Therefore, if you >>>>>>>>> think there are additional benefits to doing this in the HA >>>>>>>>> then you need to tell us. >>>>>>>>>=20 >>>>>>>>> The bottom line is this: MIP works by letting the MN install >>>>>>>>> bindings in the HA. If you want things to work in reverse you >>>>>>>>> need to justify it. I can't see any justifications because >>>>>>>>> you're not answering my questions on your scenarios. So, count >>>>>>>>> me out on the reverse direction :). >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> For >>>>>>>>>> me those I wrote about are benefits or potential benefits if you >>>>>>>>>> want. >>>>>>>>>=20 >>>>>>>>> =3D> No you didn't. You wrote about things that can be done. Many >>>>>>>>> things can be done by many entities, the question is why the HA >>>>>>>>> and not the MN. >>>>>>>>>=20 >>>>>>>>>> One important thing in the discussion, although mentioned, but >>>>>>>>>> forgotten later is that by making rules distribution one way >>>>>>>>>> only, we do create limitation for benefits, or potential >>>>>>>>>> benefits if this sounds better. >>>>>>>>>=20 >>>>>>>>> =3D> Well, we won't know what we're missing unless someone tells us= . >>>>>>>>> So far no one has mentioned the advantages of doing things in >>>>>>>>> the reverse direction. >>>>>>>>> There is always something missing from a protocol (it's >>>>>>>>> engineering), the question us whether it's significant or worth >>>>>>>>> the trouble. >>>>>>>>>=20 >>>>>>>>> Hesham >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> /yuri >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>>> Sent: Wednesday, June 03, 2009 10:10 AM >>>>>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>>> Cc: mext@ietf.org >>>>>>>>>> Subject: Re: [MEXT] Important considerations for >>>>>>>>>> directionality of flowbindings >>>>>>>>>>=20 >>>>>>>>>> Yuri, >>>>>>>>>>=20 >>>>>>>>>> I can't parse those events you refer to. I'l answer both emails = here. >>>>>>>>>> First the events you refer to: >>>>>>>>>>=20 >>>>>>>>>>>> - network condition towards CN(s) >>>>>>>>>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>>>>>>>>=20 >>>>>>>>>> =3D> What's the event? A change in those conditions? The MN >>>>>>>>>> knows the conditions of the e2e path as well as or better than t= he >>>>>>>>>> HA. >>>>>>>>>> What is the benefit of having the HA send a hint and how >>>>>>>>>> reliable is that hint anyway? >>>>>>>>>>=20 >>>>>>>>>>>> - Access provider (any access, not necessarily wireless) who >>>>>>>>>>>> offeres HA services preferences change >>>>>>>>>>=20 >>>>>>>>>> =3D> Preferences change to what?? How does it know if such >>>>>>>>>> change works for the MN at all? This is way too vague to be >>>>>>>>>> able to discuss tradeoffs. >>>>>>>>>>=20 >>>>>>>>>>>> - Change of the access provider traffic to another backbone >>>>>>>>>>>> provider due to the time of the day. >>>>>>>>>>>> - Traffic condition on HA interface, which accepts traffic >>>>>>>>>>>> from MN if MN sends on some particular local interface >>>>>>>>>>=20 >>>>>>>>>> =3D> These are path changes. The HA has _no idea_ how such a >>>>>>>>>> change affects each MN/CN combination and it's "hint" can >>>>>>>>>> cause more problems than it solves. BTW, if you're talking >>>>>>>>>> about hints then we're no longer talking about installing=20 >>>>>>>>>> bindings in the MN. This is a different topic. MIP doesn't=20 >>>>>>>>>> transfer hints, it pretty much sends "orders" >>>>>>>>>> from one end to another. >>>>>>>>>>=20 >>>>>>>>>> Now to the actions required by the MN: >>>>>>>>>>=20 >>>>>>>>>>> - reject, >>>>>>>>>>> - re-evaluate and reject >>>>>>>>>>> - re-evaluate and accept >>>>>>>>>>> - accept >>>>>>>>>>=20 >>>>>>>>>> =3D> First, by assuming that the MN can reject the "hint" as you=20 >>>>>>>>>> call it you invalidate the whole argument for the HA to install=20 >>>>>>>>>> rules. >>>>>>>>>> Rejecting a hint or even evaluating it means that the MN knows m= ore. >>>>>>>>>> Therefore, the HA's hint is a complete waste of bandwidth. >>>>>>>>>>=20 >>>>>>>>>> I'm still confused about the _benefits_ you see here. Or are=20 >>>>>>>>>> you assuming that the MN can't know those hints without the=20 >>>>>>>>>> HA's involvement? But if you're assuming that, then how can it=20 >>>>>>>>>> reject the hints? This whole proposal makes no sense to me at=20 >>>>>>>>>> all. Not to mention the complexity you implicitly assume in=20 >>>>>>>>>> order to generate those, hopefully reliable, hints. >>>>>>>>>>=20 >>>>>>>>>> Hesham >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 3/06/09 5:23 PM, "Yuri Ismailov"=20 >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hesham, >>>>>>>>>>>=20 >>>>>>>>>>> In my view these are events not scenarious. These events are=20 >>>>>>>>>>> known by HA but not MN. If HA acts upon events, given that it=20 >>>>>>>>>>> knows somewhat more about MN, not only IP addresses, it (HA)=20 >>>>>>>>>>> can generate new rules and send them as hint to MN. Back=20 >>>>>>>>>>> again, MN has four >>>>>>>>>>> options: >>>>>>>>>>>=20 >>>>>>>>>>> The benefit will be obviously that the new rules (if=20 >>>>>>>>>>> accepted) may llead to a better overall communication=20 >>>>>>>>>>> characteristics. >>>>>>>>>>>=20 >>>>>>>>>>> /yuri >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> =3D> I'm trying to understand what you mean above. These are=20 >>>>>>>>>>> all scenarios, the question is: What is the benefit for the=20 >>>>>>>>>>> HA to transfer rules? The HA will not know the path between=20 >>>>>>>>>>> the MN and CN more than either node does. So I don't=20 >>>>>>>>>>> understand what _benefits_ you see here. >>>>>>>>>>>=20 >>>>>>>>>>> Hesham >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Pretty much sure that there are more examples and I=20 >>>>>>>>>>>> encourage to think about those not from MN point of view but=20 >>>>>>>>>>>> rather from the HA service provider. >>>>>>>>>>>>=20 >>>>>>>>>>>> /yuri >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>>>>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>>>>> Cc: mext@ietf.org >>>>>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>>>>> directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Yuri, >>>>>>>>>>>>=20 >>>>>>>>>>>> It is just rules TRANSFER which is the matter of MIP. So=20 >>>>>>>>>>>> where >>>>>>>>>>>> is the logic when saying that MN to HA rules transfer is a=20 >>>>>>>>>>>> practical engineering and HA to MN is an academic interest? >>>>>>>>>>>>=20 >>>>>>>>>>>> =3D> I think we've (I'm including myself) highlighted several=20 >>>>>>>>>>>> reasons for why it makes little sense to transfer rules from=20 >>>>>>>>>>>> HA to MN. >>>>>>>>>>>> Instead of rat-holing on theory Vs practice, you (or others=20 >>>>>>>>>>>> advocating the other direction) need to come up with reasons=20 >>>>>>>>>>>> for doing things this way. This way we can think like=20 >>>>>>>>>>>> engineers about tradeoffs. >>>>>>>>>>>> Absent that, I don't see any point in having theory Vs=20 >>>>>>>>>>>> practice high level discussions, which will lead nowhere. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards >>>>>>>>>>>> Yuri >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>>>>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>>>>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>>>>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>>>>> directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi Pierrick, >>>>>>>>>>>>=20 >>>>>>>>>>>> On Jun 2, 2009, at 4:11 PM,=20 >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>> Please see inline comment. >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>> Pierrick >>>>>>>>>>>>=20 >>>>>>>>>>>> ________________________________________ >>>>>>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>>> De la part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:3= 5 =C0 : >>>>>>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important=20 >>>>>>>>>>>> considerations for directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham, >>>>>>>>>>>> This is nice story and makes some sense for the discssion,=20 >>>>>>>>>>>> however some details are ommited. In your adventure with=20 >>>>>>>>>>>> the helpdesk, it (the >>>>>>>>>>>> helpdesk) is a third party service and thus your=20 >>>>>>>>>>>> conclusions make sence. >>>>>>>>>>>> Think of the situation when superior of a heldesk person=20 >>>>>>>>>>>> will tell him/her to check access point in some room. Would=20 >>>>>>>>>>>> it be the same reaction? I assume not. By that I mean that=20 >>>>>>>>>>>> if, for example, I'll install home agent in my home=20 >>>>>>>>>>>> network, I can make it know anything I want about MN, and=20 >>>>>>>>>>>> more intresting is that how I will do it, does not require=20 >>>>>>>>>>>> any standardization. >>>>>>>>>>>> In other words, I'm superior of my HA. >>>>>>>>>>>> This situation is not unthinkable, I personally believe=20 >>>>>>>>>>>> that this is much more efficient way of using HA=20 >>>>>>>>>>>> fnctionality as opposed to big service providers who will=20 >>>>>>>>>>>> have to fight with scalability and performance. >>>>>>>>>>>> However, one does not exclude another. >>>>>>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> The difference between policy and rules is not only a=20 >>>>>>>>>>>> matter of conversion. A policy, is a static, or=20 >>>>>>>>>>>> quasi-static, set of guidance for the MN (e.g use access=20 >>>>>>>>>>>> network X for application type >>>>>>>>>>>> A,...) while a rule update requires to be more dynamic. I mean= : >>>>>>>>>>>> eventually a policy could be updated depending on network=20 >>>>>>>>>>>> condition (e.g if X overloaded, use access network Y for=20 >>>>>>>>>>>> application type A,...) but a rule reacts on local triggers (e= .g. >>>>>>>>>>>> modification of the radio link >>>>>>>>>>>> quality) with a shorter period of variation. So, IMHO,=20 >>>>>>>>>>>> there is no requirement for updating policy on a short=20 >>>>>>>>>>>> period and out-of-band mechanism can be used (e.g. IEEE >>>>>>>>>>>> 802.21 in push mode,...). >>>>>>>>>>>>=20 >>>>>>>>>>>> Fully agree! >>>>>>>>>>>> This is why I do not support the exchange of rules from the=20 >>>>>>>>>>>> HA to the MN. >>>>>>>>>>>> Policies may be exchanged from the HA to the MN, but MIP is=20 >>>>>>>>>>>> definitely not the protocol to transport them. >>>>>>>>>>>>=20 >>>>>>>>>>>> Nicolas >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> My 2 cents... >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Is there any reason to restrict where such convertion takes pl= ace? >>>>>>>>>>>> True >>>>>>>>>>>> that a HA does not know what is going on in the access=20 >>>>>>>>>>>> network, on the other hand HA may know what is the network=20 >>>>>>>>>>>> condition between HA and correspondent node. Either of this=20 >>>>>>>>>>>> information is important, if not equally important. >>>>>>>>>>>> It is not really difficult to let an MN to reject rules=20 >>>>>>>>>>>> sent by HA, which in my view would be quite natural. This=20 >>>>>>>>>>>> implies that HA must follow the rules installed by MN until=20 >>>>>>>>>>>> explicit acceptance has been received from MN. >>>>>>>>>>>> Such procedure is very similar to an MN beahviour when=20 >>>>>>>>>>>> initiating new BU, where MN is not supposed to send any=20 >>>>>>>>>>>> traffic before BU confirmation. >>>>>>>>>>>> BTW, what is the numerical representation of "rough consensus"= ? >>>>>>>>>>>> I assume is when majority is for, is it so? >>>>>>>>>>>> Yuri >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>>> On Behalf Of Hesham Soliman >>>>>>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>>>>>> To: mext >>>>>>>>>>>> Subject: [MEXT] Important considerations for directionality=20 >>>>>>>>>>>> of flow bindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>> I've always been a fan of the IETF's tradition of rough=20 >>>>>>>>>>>> concensus (as opposed to voting). To me, this implies that=20 >>>>>>>>>>>> you need to get your point across and get other people to=20 >>>>>>>>>>>> see that point of view. >>>>>>>>>>>> As opposed to other organisations that require their=20 >>>>>>>>>>>> members to vote and end up with rigid political positions. >>>>>>>>>>>>=20 >>>>>>>>>>>> The chairs asked us about the directionality question of=20 >>>>>>>>>>>> the flows bindings. >>>>>>>>>>>> On the charter question, I said that the charter doesn't=20 >>>>>>>>>>>> need to mention how a solution should work, but rather what=20 >>>>>>>>>>>> problem needs to be solved. >>>>>>>>>>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>>>>>>>>>> transferring rules "between" the MN and HA without=20 >>>>>>>>>>>> mentioning directions. >>>>>>>>>>>>=20 >>>>>>>>>>>> Nevertheless, we still need to agree on identifying the=20 >>>>>>>>>>>> requirement for the solution. And when it comes to this,=20 >>>>>>>>>>>> I'm strongly against voting and I'll practice this by=20 >>>>>>>>>>>> explaining in this email why I think rules can not be=20 >>>>>>>>>>>> transferred from the HA to the MN and that the only=20 >>>>>>>>>>>> direction that makes sense in MIP is >>>>>>>>>>>> MN->HA. I'll deliberately ignore arguments like "some=20 >>>>>>>>>>>> MN->people want >>>>>>>>>>>> this" or "an SDO wants this". They fall under the=20 >>>>>>>>>>>> "meaningless words" >>>>>>>>>>>> category and I'm incapable of discussing them because they=20 >>>>>>>>>>>> come with voting attitudes. They all need to be justified=20 >>>>>>>>>>>> if the WG wants to have a technical _discussion_. >>>>>>>>>>>>=20 >>>>>>>>>>>> Here are my reasons: >>>>>>>>>>>>=20 >>>>>>>>>>>> 1. The HA does not know whether a CoA is tied to a certain=20 >>>>>>>>>>>> access technology. It is one thing for the HA to send a=20 >>>>>>>>>>>> message saying "forward port 80 traffic on a wifi link" (a >>>>>>>>>>>> policy) and a completely different thing to say "forward=20 >>>>>>>>>>>> port 80 traffic using CoA 3ffe::1" >>>>>>>>>>>> (a rule). >>>>>>>>>>>>=20 >>>>>>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem now? >>>>>>>>>>>> The problem is that the HA has no idea about dynamic=20 >>>>>>>>>>>> changes on that wifi link. It doesn't know if it's=20 >>>>>>>>>>>> congested, it doesn't know what application is using port=20 >>>>>>>>>>>> 80 (it doesn't have to be web >>>>>>>>>>>> traffic) or port 8000 for that matter and doesn't even know=20 >>>>>>>>>>>> if the AP of that wifi link works at all. >>>>>>>>>>>> Finally, it >>>>>>>>>>>> doesn't know the user's policies or other admin policies=20 >>>>>>>>>>>> for that MN. >>>>>>>>>>>> This type of information needs to be sent regularly because=20 >>>>>>>>>>>> it changes all the time and requires serious cross layer=20 >>>>>>>>>>>> integration including sometimes layer 8 integration! It's=20 >>>>>>>>>>>> completely impractical. >>>>>>>>>>>>=20 >>>>>>>>>>>> 3. If the HA installed rules in the MN, what happens if the=20 >>>>>>>>>>>> MN wants to change those rules. Say the wifi link went=20 >>>>>>>>>>>> down, or the MN's wifi interface went down and it wants to=20 >>>>>>>>>>>> move that traffic to another interface. Would the HA reject=20 >>>>>>>>>>>> such move? >>>>>>>>>>>> Does the MN have to justify to the HA why it needs to move=20 >>>>>>>>>>>> traffic? Does that involve writing a letter perhaps? >>>>>>>>>>>> If you say "well in that case, the HA should let the MN=20 >>>>>>>>>>>> move the traffic" >>>>>>>>>>>> then I'll ask you: what's the point of having the HA=20 >>>>>>>>>>>> install this stuff if it has no authority and how does it=20 >>>>>>>>>>>> know the reason for the MN's movement of the flow? >>>>>>>>>>>> The way to control how users do things is to incentivise=20 >>>>>>>>>>>> them with charging models and show them that things work=20 >>>>>>>>>>>> better on certain technologies, not by installing rules=20 >>>>>>>>>>>> that can't be followed. It's a broken mindset and we've=20 >>>>>>>>>>>> known that it's broken for a long time. >>>>>>>>>>>>=20 >>>>>>>>>>>> 4. Some people mentioned that the HA should be able to=20 >>>>>>>>>>>> revoke flows on the MN. I'm perfectly fine with that, just=20 >>>>>>>>>>>> extend the binding revocation draft to handle flows and the=20 >>>>>>>>>>>> rest is pretty straight forward. >>>>>>>>>>>>=20 >>>>>>>>>>>> Finally, I'll indulge in a true story that happened to me a=20 >>>>>>>>>>>> few years ago when I found that my wifi link wasn't working=20 >>>>>>>>>>>> in a hotel (no >>>>>>>>>>>> radio) >>>>>>>>>>>> and called the help desk. He insisted that the link was up=20 >>>>>>>>>>>> an I insisted that it wasn't. When I asked him to tell me=20 >>>>>>>>>>>> how he knows the link is up he said: I can ping the AP! Of=20 >>>>>>>>>>>> course after another >>>>>>>>>>>> 5 minutes of trying to convince him that pinging the AP=20 >>>>>>>>>>>> doesn't mean the radio is actually working he sent someone=20 >>>>>>>>>>>> to the hotel who in turn realised that the radio was not worki= ng. >>>>>>>>>>>> For those people who want rules to be transferred from the=20 >>>>>>>>>>>> HA to the MN, please think of your HA as this help desk=20 >>>>>>>>>>>> person, i.e. >>>>>>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>>>>>=20 >>>>>>>>>>>> I hope this helps with the realisation that decisions can't=20 >>>>>>>>>>>> be made here based on voting and that there is little merit=20 >>>>>>>>>>>> to transferring rules from the HA to the MN. Policies can=20 >>>>>>>>>>>> be transferred without any problems, but not rules. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From yuri.ismailov@ericsson.com Tue Jun 9 01:22:08 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A48E3A67F2 for ; Tue, 9 Jun 2009 01:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.091 X-Spam-Level: X-Spam-Status: No, score=-8.091 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 XfhYrkRS+O4O for ; Tue, 9 Jun 2009 01:22:03 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C59E428C16B for ; Tue, 9 Jun 2009 01:22:01 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9cae00000140d-f3-4a2e1b9eda8b Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 13.86.05133.E9B1E2A4; Tue, 9 Jun 2009 10:21:50 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 10:21:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Jun 2009 10:21:48 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8A== References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 09 Jun 2009 08:21:48.0714 (UTC) FILETIME=[5586A8A0:01C9E8DB] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 08:22:08 -0000 Hesham, See inline (have you read what I wrote before answering?) -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Tuesday, June 09, 2009 9:38 AM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings On 9/06/09 5:07 PM, "Yuri Ismailov" wrote: > Hesham, below is my attempt to understand what the following means=20 > (not an easy task though) >=20 > =20 >> =3D> So now that we agree that we are only talking about CoAs then I=20 >> don't see any meaningful information coming from the HA. Hints about=20 >> upstream routing changes ...etc are relevant to HoA selection (even=20 >> if the HoA is not tied to a physical interface it doesn't matter).=20 >> This is an interesting problem to discuss but I want to be clear on=20 >> its context. So to summarise my opinion: >> HA-> MN hints (not rules) may be relevant for intial HoA selection=20 >> HA-> for >> certain connections. The types of hints and how to formulate this in=20 >> a global manner can lead to interesting work (although it's a complex = >> problem). However, this information is not in anyway relevant to=20 >> CoA/physical interface selection on the MN. >=20 > First, is that we have agreed already that we are talking about = interfaces. > Yes, we are talking about interfaces configured with CoA. Interfaces=20 > configured with HoA does not give any information about=20 > characteristices of interfaces configured with CoA, thus choosing HoA=20 > or HA can not provide any meaningful information about access=20 > characteristics. Thus it is not clear at all where from comes idea = about relevance to HA selection. =3D> The hints that you were suggesting that the HA sends are only = relevant to HoA selection. Do you agree? No, I explained above why. HoA selection is meaningless in general = because does not provide any usable information for selection of = interfaces. > In all my examples (e.g. the latest one about broadband operators) it=20 > does not matter which HA (HoA) is used. All what matters is which=20 > access MN uses and if there was traffic shaping policy applied to that = access by an access provider. > We have agreed that MN can not know about the later. HA can. =3D> No! You were talking about traffic shaping by the HA or its = upstream ISP. What do you mean by "provider" above? Where is the traffic being = impacted? I'm not aware of any HA installed by any of access providers at the = moment (any information about that would be highly appreciated). Traffic = shaping, on the other hand, is applied in reality by some access = providers, which have a quota on the amount of traffic sent within a = period of time, typically over a month. By provider I mean any provider who offers connectctivity to global = Internet. A provider can offer such connectivity over single access = technology or multiple different access technologies >=20 > Second, is that we are talking about sending rules from HA to MN. I=20 > call these rules hints, because and only because in my view MN should=20 > have rights to ignore the rules from HA. Both transportwise and=20 > contentwise, we are still talking about rules. At the moment I do not=20 > see any specific need for specific types of hints. =3D> If we're talking about CoA selection I don't see any relevance to = those hints. The only way you can show there is relevance is by = providing an example. The example you provided had no relevance to CoA = selection. I don't understand why we need to go back two emails again. = If you still think your scenario had relevance to CoA selection then = please respond to my earlier response to your scenario. Here I call you to read my emails as well. I explained that CoA = selection is the result of interface selection. We are talking about = selecting interfaces based on their characteristics for particular = flows. Information about downgrading the link performance is relevant to = the communication charachteristics of flows sent through that interface. >=20 > Information about the fact that up/down link from/to HA for a=20 > particular interface was downgraded is very relevant for MN because=20 > based on this information MN can select another interface for some of=20 > its flows and make correspondent move. =3D> Are you saying the MN will notify the HA everytime I do this: Ifdown eth1: ifup eth1 Why on earth would you do that? If you had flows running on eth1 before you have performed "ifdown eth1" = and you want this flows to continue, you apperantly should move flows to = another interface. If the current rule set in the MN changes, then the = rule set in the HA has to be synchronized with what MN has generated due = to "ifdown eth1" event. If this is not the case then what is the objactive of > interfaces selection? If better choice of interface for applications=20 > is not an objective then why bother about flow mobility at all? =3D> I don't understand what you're saying Yuri. Please respond to my = earlier email which responded to your scenario. I can't see how you = still think that the HA can influence CoA selection. The HA is sending the rules where particlar flow(s) are suggested to = move to another interface. /yuri Hesham >=20 > Regards > Yuri >=20 >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Monday, June 08, 2009 4:29 PM > To: Yuri Ismailov; Nicolas Montavont;=20 > pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of=20 > flowbindings >=20 >=20 >=20 >=20 > On 9/06/09 12:12 AM, "Yuri Ismailov" = wrote: >=20 >> =20 >> =3D> Yes but I still think you're talking about something else. The=20 >> interface you're talking about seems to be associated with the HoA. >> This is the only case where I can see the relevance of HA hints (not=20 >> rules). The interfaces I'm talking about and discussed in the context = >> of flow bindings are those associated with CoAs. There is nothing=20 >> coming from the HA about its links ...etc that can have any impact on = >> CoA selection. >>=20 >> Hesham >> here I tend to agree. I actually ment interfaces with CoA, but now=20 >> realized that in such configuration, where each of interfaces has=20 >> it's own HA configured, it is most likely that each of interfaces=20 >> will have different HoA. >> Once this is the case then moving a flow between those interfaces=20 >> will lead to change of HoA. As we are in MIP context, I would better=20 >> avoid that. In the whole discussion I mean interafces with CoA=20 >> because selection of HoA and/or associated to it interface can not be = >> based on physical characteristics of that interface. >=20 > =3D> Sounds fine to me. >=20 >>=20 >> So the valid and meaningful scenario is moving flow(s) between=20 >> interfaces associated with the same HA, whether all interfaces of the = >> MN or some of them will be configured this way does not really = matter. >>=20 >> Fine with me. Should we finalize then? As I see it, once there is a=20 >> meaningful information, which can be sent in HA -> MN direction, then = >> MN can use it for re-evaluting policies and producing the new set of=20 >> rules. Definetely not at all times new rules will be produced, they=20 >> may stay unchanged, as it will be the case with many other events=20 >> taking place at either side: MN or HA. >>=20 >> Is that correct? >=20 > =3D> So now that we agree that we are only talking about CoAs then I=20 > don't see any meaningful information coming from the HA. Hints about=20 > upstream routing changes ...etc are relevant to HoA selection (even if = > the HoA is not tied to a physical interface it doesn't matter). This=20 > is an interesting problem to discuss but I want to be clear on its = context. So to summarise my opinion: > HA-> MN hints (not rules) may be relevant for intial HoA selection for > certain connections. The types of hints and how to formulate this in a = > global manner can lead to interesting work (although it's a complex = problem). > However, this information is not in anyway relevant to CoA/physical=20 > interface selection on the MN. >=20 > Hesham >=20 >=20 >>=20 >> Regards >> Yuri >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Monday, June 08, 2009 2:00 PM >> To: Yuri Ismailov; Nicolas Montavont;=20 >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of=20 >> flowbindings >>=20 >> Yuri, >>=20 >> I think we're getting close here. >>=20 >>=20 >> On 8/06/09 6:29 PM, "Yuri Ismailov" = wrote: >>=20 >>> Hesham, It looks like that the only point of disagreement is about=20 >>> changing HA and mapping between HA and access. >>> Some explanations of what I mean below: >>>=20 >>>=20 >>> 1. Changing HA. >>> As it follows from group charter change of HA is in the plans of=20 >>> MEXT WG. I assume that this is going to be a separate work item=20 >>> because the reason specified for that is very specific and relates=20 >>> to deployment more than to flow mobility. Do not want to speculate,=20 >>> about this right now but the change of HA does not necessarily means = >>> change of rules. >>> So the proposal is to not to discuss change of HA as you suggested. >>=20 >> =3D> Agreed. >>=20 >>>=20 >>> 2. In my example I do not mean change of HA as an explicit procedure = >>> specified separately. One confirmation to that is that single HA for = >>> all interfaces is included and valid option. Based on the HA -> MN=20 >>> exchange, the MN may perform interface selection procedure and may=20 >>> choose another interface for some flow(s). In multiple HA case it=20 >>> will result of the rules update MN -> HA to the HA which is relevant = >>> for the new interface chosen for flows. Please notice, There is=20 >>> nothing about HA change, only about interface selection. >>=20 >> =3D> Yes but I still think you're talking about something else. The=20 >> interface you're talking about seems to be associated with the HoA. >> This is the only case where I can see the relevance of HA hints (not=20 >> rules). The interfaces I'm talking about and discussed in the context = >> of flow bindings are those associated with CoAs. There is nothing=20 >> coming from the HA about its links ...etc that can have any impact on = >> CoA selection. >>=20 >>>=20 >>> 3. I do not map HA and access. It is allowed for any access provider = >>> to offer HA service and once this is the case it will be so. Thus an = >>> MN can have multiple HA configured for the use on different = interfaces. >>=20 >> =3D> Good, we agree on that too. >>=20 >> Hesham >>=20 >>>=20 >>> Regards >>> Yuri >>>=20 >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Friday, June 05, 2009 4:18 PM >>> To: Yuri Ismailov; Nicolas Montavont;=20 >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>> flowbindings >>>=20 >>>=20 >>>=20 >>>> First is that I assume that we have simulteneous multiaccess in=20 >>>> mind, i.e. MN has more than one interface to choose from for its=20 >>>> flows. If this is not the case then I will stop the discussion.=20 >>>> This assumption is based on the fact that we are (I hope at least)=20 >>>> discussing flow mobility. >>>=20 >>> =3D> Sure. >>>=20 >>>>=20 >>>> Secondly, I consider that MN chooses an interface but not CoA. I=20 >>>> gave a though about that and did not come up with any information=20 >>>> which can be derived from CoA in order to choose it. An interface=20 >>>> has at least expected characteristics, thus can be a subject of=20 >>>> choice. Any clarification about that would be appreciated. >>> =3D> An application would choose an interface, but of course the IP=20 >>> stack selects the corresponding address. I'm sure there is no=20 >>> disagreement there. >>>=20 >>>>=20 >>>> Next assumptions are about possible configurations of HA >>>> - Single HA for all interfaces configured in the mobile. HA can=20 >>>> belong to any of the access providers of each of access technology=20 >>>> used by MN. >>>=20 >>> =3D> Ok. >>>=20 >>>>=20 >>>> - One HA per access or set of accesses, which is subset of all=20 >>>> access techologies presented or potentially may be presented=20 >>>> (detached >>>> devices) in MN. >>>=20 >>> =3D> Now you're getting into a different problem space from flow = mobility. >>> This is why I wanted you to break the scenario down. We are not=20 >>> dealing with multiple HoAs in this work item, we're dealing with=20 >>> multiple CoAs, i.e. One HoA. >>>=20 >>>> Anticipating numerous questions about that can say that I looked at = >>>> such configuration and did not find anything strange with it, i.e. >>>> (1) it works, >>>> (2) it does not require any change to MIP or any other of its=20 >>>> extensions. (3) Configuration is performed per interface and does=20 >>>> not introduce any ambiguities. (4) it is natural for access=20 >>>> provider to offer HA service. >>>=20 >>> =3D> Yes of course it works but as I read this I'm guessing that you = >>> want the MN to change HoA. This is not the problem we're discussing=20 >>> in this WG. >>> Another issue, I'm not comfortable with the wording of "HA per = access" >>> because they're not tied to access. Let's just say there are=20 >>> multiple Has and not associate it with an access. >>>=20 >>>>=20 >>>> - "Residential" HA. Assumption is that it can be either one of HA's = >>>> or a single HA for all types of accesses. This is the matter of MN=20 >>>> configuration. >>>> "Residential". >>>=20 >>> =3D> Please don't tie HA to access. >>>=20 >>>>=20 >>>> - Any HA may have multiple interfaces, e.g. "residential" HA may be = >>>> connected to mobile broadband, DSL, etc. >>>=20 >>> =3D> sure >>>=20 >>>>=20 >>>> Next assumption comes from the example (e.g. latest one) >>>> - Traffic shaping is applied in both directions (up/down) link (in=20 >>>> practice this is the case). >>>> - Traffic shaping (TS) is applied to user subscription. In other=20 >>>> words TS is applied to packets belonging to a particular=20 >>>> subscription but not to an aggregated traffic on gateway = interfaces. >>>> HA is not necessary (however, nothing prevents from that) a gateway = >>>> where TS is applied. >>>>=20 >>>>=20 >>>> I hope that I have not missed something, although it may be = possible. >>>> If we can agree on that or correct if something is wrong here and=20 >>>> agree later then we know how to proceed further on >>>=20 >>> =3D> Your scenario is fine (with the wording changes for tying Has = to access). >>> But I want to pre-empt any suggestion that the HA will tell the MN=20 >>> to use a different HoA. This is very possible but it's not the=20 >>> problem being discussed here. It may well be something for charter=20 >>> discussion but it has zero impact on flow bindings for multiple = CoAs. >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> /yuri >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Friday, June 05, 2009 11:37 AM >>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of=20 >>>> flowbindings >>>>=20 >>>> Yuri, >>>>=20 >>>>=20 >>>>> Still not clear for me why you call scenarious invalid? >>>>> Some broadband providers (this is used in practice) have quota on=20 >>>>> the amount of traffic sent by users. Once quota is exceeded=20 >>>>> provider downgardes outgoing traffic from its network to 64Kbs=20 >>>>> (this figure is the real example from real provider). Such=20 >>>>> combination of to paths, where one is high speed, lets say 10 Mbs=20 >>>>> and another one is 64Kbs is quite crusual to apps running on top = of TCP. >>>>> Not for all types of traffic though. >>>>=20 >>>> =3D> Yes I know the scenario but I keep saying to you that the = change=20 >>>> in upstream routing in the HA has nothing to do with CoA selection=20 >>>> by the MN in the visited network. If anything, you want the MN to=20 >>>> change it's HoA depending on how the switch to another upstream ISP = works. >>>> It's a completely irrelevant issue to this discussion. Do you = agree? >>>> If not why not? I really want to see an answer to this point. >>>>=20 >>>> =20 >>>>=20 >>>>=20 >>>>>=20 >>>>> MN can not know about this situation. Nobody will send this=20 >>>>> information to MN. >>>>=20 >>>> =3D> Yes and if it knows what will it do??? If you can answer that=20 >>>> you will fix the deadlock we have. >>>>=20 >>>>> That means that MN will choose its interfaces based on its=20 >>>>> knowledge about 10Mbs link capabilities. >>>>=20 >>>> =3D> You're talking about two different things. The MN doesn't = choose=20 >>>> the HA's outgoing interface! What am I missing? >>>>=20 >>>> Obtaining this isnformation from HA is quite >>>>> significant to make a better decision about choice of interfaces=20 >>>>> for its flows. >>>>> This is concrete example of what happens in the reality. >>>>> Do you consider that this information will be useless for MN? >>>>=20 >>>> =3D> Completely useless. Unless I'm missing something in your = scenario. >>>> Just write down step by step what will happen and include messages. >>>> I don't see how this can possibly be relevant to the MN. >>>>=20 >>>> Hesham >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> /yuri >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: Thursday, June 04, 2009 4:38 PM >>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>> pierrick.seite@orange-ftgroup.com >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of = >>>>> flowbindings >>>>>=20 >>>>> Yuri, >>>>>=20 >>>>>=20 >>>>> On 5/06/09 12:01 AM, "Yuri Ismailov" = wrote: >>>>>=20 >>>>>> Hesham, >>>>>>=20 >>>>>> I provided several scenarious which you said are invalid. This is = >>>>>> where my conclusion about standpoint comes from. >>>>>> Whether you call hints policies or rules it does not change what=20 >>>>>> information can be provided by HA to MN. >>>>>=20 >>>>> =3D> It changes the outcome for the work item we're discussing. = I'm=20 >>>>> trying to come to a conclusion on this and there is a huge=20 >>>>> difference between transferring policies and installing flow = bindings. >>>>>=20 >>>>>> By sending rules HA does not install anything in MN. Likewise, MN = >>>>>> does not install rules in HA, it informs HA about currently made = choices. >>>>>> As I remember rules will not be valid until proper Ack arrival,=20 >>>>>> which for me means that may not be instantiated at all. >>>>>> Niether rules nor polices are specific to MIP. As I wrote those=20 >>>>>> can be exchanged between hosts without any MIP implementation,=20 >>>>>> just for access selection purposes. Once it was decided to make=20 >>>>>> it as part of MIP protocol, I'm fine with that. Do not have any=20 >>>>>> idea to discuss this, while personally consider that the work on=20 >>>>>> rules transfer can very well fit into the MEXT group but as a=20 >>>>>> separate work item, but this is not the case now, so good enough = the way it is. >>>>>> And back again, it really gets repeated, so will lead to nowhere, = >>>>>> you've got my arguments and tell that the information, which I'm=20 >>>>>> talking about, is not usefull. What can I say more? I can put you = >>>>>> on my position and start asking questions instead of answering. >>>>>> So, why it is not usefull? >>>>>=20 >>>>> =3D> I explained why the specific information you mentioned was = not=20 >>>>> useful/useable by the MN and this is what I referred to as = unanswered. >>>>> Because if you agree with my previous explanations then we don't=20 >>>>> need to discuss it further. If you disagree you certainly didn't=20 >>>>> tell me why. You have the charge of proof because you want to=20 >>>>> change the way MIP works currently, that's all I'm trying to say. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>>=20 >>>>>> /yuri >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>> Sent: Thursday, June 04, 2009 4:00 AM >>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>> pierrick.seite@orange-ftgroup.com >>>>>> Cc: mext@ietf.org >>>>>> Subject: Re: [MEXT] Important considerations for directionality=20 >>>>>> of flowbindings >>>>>>=20 >>>>>> Yuri, >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Missing is additional information which may be helpful in making = >>>>>>> better decision about interface selection by MN. >>>>>>> Which information is that I wrote in my previous emails. Back to = >>>>>>> my examples (not all, do not want to repeat myself). If HA will=20 >>>>>>> have changed traffic shaping parameters on one of the incoming=20 >>>>>>> or outgoing interfaces, this will be important information for = MN to know. >>>>>>> We have agreed already that whether this information important=20 >>>>>>> or not, benfitial or not is a matter of standpoint. >>>>>>=20 >>>>>> =3D> I don't agree or like to think that it's a matter of = standpoint. >>>>>> That's why I asked you on every point you raised and compared=20 >>>>>> this to the MN's knowledge on e2e basis. Once we have = "standpoints" >>>>>> then we're getting outside the technical realm. The reason I=20 >>>>>> don't think it's useful is that this information cannot be used=20 >>>>>> by the MN to select a CoA. I've already stated that before and=20 >>>>>> you seemed to agree so I don't know why you repeat this as a=20 >>>>>> reason for the HA to install filters in the MN. Let me say it >>>>>> again: There is no correlation between the routing on the HA's=20 >>>>>> upstream interfaces/ISP with the MN's selection of a CoA. >>>>>>=20 >>>>>>> I consider that knowing more is a benefit and will help to get=20 >>>>>>> better result. >>>>>>>=20 >>>>>>> My point is still the same. I see the reverse rules sending as=20 >>>>>>> possibility to provide more information to the MN, thus make MN=20 >>>>>>> to get to better decision about interface selection for its = flows. >>>>>>> This point has not changed since the beginning of the = discussion. >>>>>>=20 >>>>>> =3D> This is why we're not making progress IMO: >>>>>>=20 >>>>>> 1. The hints you refer to are not the same things as installing=20 >>>>>> rules on the MN. Completely different information in fact. You've = >>>>>> essentially proved that when you suggested that the MN can accept = >>>>>> or reject them. So, let's not call them rules. The more direct=20 >>>>>> word for what you want to send is policies >>>>>>=20 >>>>>> 2. You didn't provide a valid scenario that we can discuss as to=20 >>>>>> why it's needed or how it could work. I've asked numerous=20 >>>>>> questions in each email that were not answered (with the=20 >>>>>> exception of the last email). It's not possible to progress the=20 >>>>>> discussion without answering each others' >>>>>> questions. You can go back through the threads and verify this. >>>>>>=20 >>>>>> 3. If we're sending rules from the HA to the MN and the MN can=20 >>>>>> reject those rules then the whole exercise is pointless. You=20 >>>>>> really want to send policies not rules. I can imagine those=20 >>>>>> policies being one of the inputs that the MN uses to make a=20 >>>>>> decision. I still fail to see how anything happening on the HA's=20 >>>>>> upstream interfaces/ISP link can possibly influence the MN's=20 >>>>>> decision for CoA selection. >>>>>> This is another unanswered question. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>>=20 >>>>>>> /yuri >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>> Sent: Wednesday, June 03, 2009 4:09 PM >>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>> Cc: mext@ietf.org >>>>>>> Subject: Re: [MEXT] Important considerations for directionality=20 >>>>>>> of flowbindings >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 3/06/09 10:47 PM, "Yuri Ismailov" = wrote: >>>>>>>=20 >>>>>>>> Ok, see your point, however:-) >>>>>>>>=20 >>>>>>>> The major difference here is that your are talking about CoA=20 >>>>>>>> selection and I'm talking about interface selection. Quite a=20 >>>>>>>> big difference. >>>>>>>=20 >>>>>>> =3D> No, that's not the point really. The point is that there is = >>>>>>> no relationship between CoA/interface selection on the MN and=20 >>>>>>> the upstream ISP for the home network. >>>>>>>=20 >>>>>>>> I do not see any grounds for MN to select CoA, based on what? >>>>>>>> Prefix length? >>>>>>>> While selection of an interface is based on expected=20 >>>>>>>> characteristics of the communication. Routes (up/down)link in=20 >>>>>>>> my opinion do have impact on the characteristics and this is=20 >>>>>>>> exactly the information missing in the MN when selecting = interface. >>>>>>>=20 >>>>>>> =3D> There is nothing missing for the MN to make this selection. >>>>>>> Please tell us specifically what is missing. You're changing=20 >>>>>>> points on me all the time now. >>>>>>> Lets stick to one point at a time. What's missing? >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Whenever, MN decides to move a flow, the reason can be anything = >>>>>>>> but not which CoA it has configured on each interface. >>>>>>>>=20 >>>>>>>> Another thing is that MN will notice something e2e if and only=20 >>>>>>>> if such support is implemented in the MN. >>>>>>>=20 >>>>>>> =3D> Of course, so what? >>>>>>>=20 >>>>>>> Moreover, this notice can not be made at IP layer. >>>>>>>> TCP fights alone with all problems and never tells to any other = >>>>>>>> layer what is going on. So what is left? Two options. Add this=20 >>>>>>>> support to operating system, which makes its (support)=20 >>>>>>>> existence questionable, or to applications, which is even more = questionable. >>>>>>>=20 >>>>>>> =3D> It's interesting that you think it's questionable to add = the=20 >>>>>>> support to the MN's OS but not questionable to add the support=20 >>>>>>> to the HA's OS, which will not lead to the same reliability as=20 >>>>>>> if it were done in the MN. It doesn't make sense to me. >>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Well, that's debatable, but this is clearly not a reason to=20 >>>>>>>>>> do anything. >>>>>>>>>>=20 >>>>>>>> Are you serious about that MIP may be broken because of that? >>>>>>>=20 >>>>>>> =3D> Yes! It's not designed to do what you want to do. Luckily, = in=20 >>>>>>> this case what you want, IMO, is broken anyway so it's not a = problem. >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>>=20 >>>>>>>> /yuri >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>> Sent: Wednesday, June 03, 2009 1:15 PM >>>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>> Cc: mext@ietf.org >>>>>>>> Subject: Re: [MEXT] Important considerations for directionality = >>>>>>>> of flowbindings >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Still some answers, despite knowing that in your opinion they=20 >>>>>>>>> are not benefits. >>>>>>>>>=20 >>>>>>>>> First of all MIP will not be breaked if the rules will be sent = >>>>>>>>> in both directions. >>>>>>>>=20 >>>>>>>> =3D> Well, that's debatable, but this is clearly not a reason = to=20 >>>>>>>> do anything. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> - Access provider preferences relate to the use of backbone=20 >>>>>>>>> provider, which may vary with the time of day. Changing=20 >>>>>>>>> backbone provider can make quite big difference for=20 >>>>>>>>> commnication between HA (if HA service is provided by the same = >>>>>>>>> access >>>>>>>>> provider) and CN(s). >>>>>>>>> The difference can be expressed in, let's say, number of hops, = >>>>>>>>> load, possibly something else. Such change is an event and may = >>>>>>>>> have an impact on the overall communication. This can be told=20 >>>>>>>>> directly to MN or HA. Direct communication to MN (if accepted=20 >>>>>>>>> as >>>>>>>>> benefit:-)) in such case will need standardization. >>>>>>>>> Communication of this information to HA does not (I consider=20 >>>>>>>>> this as a benefit). >>>>>>>>> HA may act upon that event, and the rest you >>>>>>>>> know: rules in reverse direction. >>>>>>>>=20 >>>>>>>> =3D> There is no need to _tell_ the MN anything. There are two=20 >>>>>>>> issues here. >>>>>>>> First, changing network conditions are best known e2e. So the=20 >>>>>>>> MN will know that anyway based on the traffic running between=20 >>>>>>>> it and the CN. >>>>>>>> The other issue is related to cost for certain times of day. >>>>>>>> This is a routing issue in the HA and has nothing to do with=20 >>>>>>>> which interface the MN selects. The selected CoA has zero=20 >>>>>>>> impact on the HA's upstream selection. Completely irrelevant = actually. >>>>>>>> Of course, as far as cost on the visited link, the MN knows = best. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> - Access provider may set up different parameters for traffic=20 >>>>>>>>> shaping for each of HA interfaces. These preferences may vary=20 >>>>>>>>> independently of change of backbone provider but dependently=20 >>>>>>>>> on the time of day. >>>>>>>>> The rest you know, whether it changes somebodies opinion. >>>>>>>>=20 >>>>>>>> =3D> But again, this has zero effect on CoA selection. The two=20 >>>>>>>> issues are completely orthogonal. Selecting CoA1 or CoA2 has=20 >>>>>>>> zero impact on the HA's upstream route. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> - I presume that in RO mode this is similar to HA mode, and=20 >>>>>>>>> I'm in when it comes to send rules in reverse direction = between CN and MN. >>>>>>>>> Benefits of doing that is that any change percieved by CN as=20 >>>>>>>>> important to react upon can be expressed in proposal of new = rules. >>>>>>>>> The sources causing changes may include but not limited to,=20 >>>>>>>>> are user, network managemnt events, application generated = events, etc. >>>>>>>>>=20 >>>>>>>>> So feel free to consider this as benefits or not >>>>>>>>=20 >>>>>>>> =3D> You seem to think that there is a relationship between=20 >>>>>>>> upstream routing and CoA selection. That's not the case at all. >>>>>>>> These are two different addresses from two different networks. >>>>>>>>=20 >>>>>>>> Hesham >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> /yuri >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>> Sent: Wednesday, June 03, 2009 11:47 AM >>>>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>> Cc: mext@ietf.org >>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>> directionality of flowbindings >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 3/06/09 7:33 PM, "Yuri Ismailov"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Hesham, >>>>>>>>>>=20 >>>>>>>>>> Whenever we talk about sending additional information, the=20 >>>>>>>>>> "waste of bandwidth" can be brought up. So I do not have an=20 >>>>>>>>>> answer for that besides speculations around it. >>>>>>>>>=20 >>>>>>>>> =3D> no no, I don't mean it literally, I mean that the message = >>>>>>>>> doesn't do anything, i.e. Has no benefit. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Speaking about benefits, everybody who knows the area is=20 >>>>>>>>>> capable of turning things up side down. I assume it is=20 >>>>>>>>>> subjective standpoint of considering things as benefits or=20 >>>>>>>>>> disadvantages and all is about to agree or disagree. >>>>>>>>>=20 >>>>>>>>> =3D> That's fine, I'm asking for benefits in your opinion not=20 >>>>>>>>> someone else's. >>>>>>>>> It's impossible to discuss this if I can't see any benefits=20 >>>>>>>>> because you didn't send any. What you sent were actions that=20 >>>>>>>>> can be done by the HA and I responded by saying that the same=20 >>>>>>>>> (or >>>>>>>>> more) information is available to the MN. Therefore, if you=20 >>>>>>>>> think there are additional benefits to doing this in the HA=20 >>>>>>>>> then you need to tell us. >>>>>>>>>=20 >>>>>>>>> The bottom line is this: MIP works by letting the MN install=20 >>>>>>>>> bindings in the HA. If you want things to work in reverse you=20 >>>>>>>>> need to justify it. I can't see any justifications because=20 >>>>>>>>> you're not answering my questions on your scenarios. So, count = >>>>>>>>> me out on the reverse direction :). >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> For >>>>>>>>>> me those I wrote about are benefits or potential benefits if=20 >>>>>>>>>> you want. >>>>>>>>>=20 >>>>>>>>> =3D> No you didn't. You wrote about things that can be done.=20 >>>>>>>>> Many things can be done by many entities, the question is why=20 >>>>>>>>> the HA and not the MN. >>>>>>>>>=20 >>>>>>>>>> One important thing in the discussion, although mentioned,=20 >>>>>>>>>> but forgotten later is that by making rules distribution one=20 >>>>>>>>>> way only, we do create limitation for benefits, or potential=20 >>>>>>>>>> benefits if this sounds better. >>>>>>>>>=20 >>>>>>>>> =3D> Well, we won't know what we're missing unless someone = tells us. >>>>>>>>> So far no one has mentioned the advantages of doing things in=20 >>>>>>>>> the reverse direction. >>>>>>>>> There is always something missing from a protocol (it's=20 >>>>>>>>> engineering), the question us whether it's significant or=20 >>>>>>>>> worth the trouble. >>>>>>>>>=20 >>>>>>>>> Hesham >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> /yuri >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>>> Sent: Wednesday, June 03, 2009 10:10 AM >>>>>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>>> Cc: mext@ietf.org >>>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>>> directionality of flowbindings >>>>>>>>>>=20 >>>>>>>>>> Yuri, >>>>>>>>>>=20 >>>>>>>>>> I can't parse those events you refer to. I'l answer both = emails here. >>>>>>>>>> First the events you refer to: >>>>>>>>>>=20 >>>>>>>>>>>> - network condition towards CN(s) >>>>>>>>>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>>>>>>>>=20 >>>>>>>>>> =3D> What's the event? A change in those conditions? The MN=20 >>>>>>>>>> knows the conditions of the e2e path as well as or better=20 >>>>>>>>>> than the HA. >>>>>>>>>> What is the benefit of having the HA send a hint and how=20 >>>>>>>>>> reliable is that hint anyway? >>>>>>>>>>=20 >>>>>>>>>>>> - Access provider (any access, not necessarily wireless)=20 >>>>>>>>>>>> who offeres HA services preferences change >>>>>>>>>>=20 >>>>>>>>>> =3D> Preferences change to what?? How does it know if such=20 >>>>>>>>>> change works for the MN at all? This is way too vague to be=20 >>>>>>>>>> able to discuss tradeoffs. >>>>>>>>>>=20 >>>>>>>>>>>> - Change of the access provider traffic to another backbone = >>>>>>>>>>>> provider due to the time of the day. >>>>>>>>>>>> - Traffic condition on HA interface, which accepts traffic=20 >>>>>>>>>>>> from MN if MN sends on some particular local interface >>>>>>>>>>=20 >>>>>>>>>> =3D> These are path changes. The HA has _no idea_ how such a=20 >>>>>>>>>> change affects each MN/CN combination and it's "hint" can=20 >>>>>>>>>> cause more problems than it solves. BTW, if you're talking=20 >>>>>>>>>> about hints then we're no longer talking about installing=20 >>>>>>>>>> bindings in the MN. This is a different topic. MIP doesn't=20 >>>>>>>>>> transfer hints, it pretty much sends "orders" >>>>>>>>>> from one end to another. >>>>>>>>>>=20 >>>>>>>>>> Now to the actions required by the MN: >>>>>>>>>>=20 >>>>>>>>>>> - reject, >>>>>>>>>>> - re-evaluate and reject >>>>>>>>>>> - re-evaluate and accept >>>>>>>>>>> - accept >>>>>>>>>>=20 >>>>>>>>>> =3D> First, by assuming that the MN can reject the "hint" as=20 >>>>>>>>>> you call it you invalidate the whole argument for the HA to=20 >>>>>>>>>> install rules. >>>>>>>>>> Rejecting a hint or even evaluating it means that the MN = knows more. >>>>>>>>>> Therefore, the HA's hint is a complete waste of bandwidth. >>>>>>>>>>=20 >>>>>>>>>> I'm still confused about the _benefits_ you see here. Or are=20 >>>>>>>>>> you assuming that the MN can't know those hints without the=20 >>>>>>>>>> HA's involvement? But if you're assuming that, then how can=20 >>>>>>>>>> it reject the hints? This whole proposal makes no sense to me = >>>>>>>>>> at all. Not to mention the complexity you implicitly assume=20 >>>>>>>>>> in order to generate those, hopefully reliable, hints. >>>>>>>>>>=20 >>>>>>>>>> Hesham >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 3/06/09 5:23 PM, "Yuri Ismailov"=20 >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hesham, >>>>>>>>>>>=20 >>>>>>>>>>> In my view these are events not scenarious. These events are = >>>>>>>>>>> known by HA but not MN. If HA acts upon events, given that=20 >>>>>>>>>>> it knows somewhat more about MN, not only IP addresses, it=20 >>>>>>>>>>> (HA) can generate new rules and send them as hint to MN.=20 >>>>>>>>>>> Back again, MN has four >>>>>>>>>>> options: >>>>>>>>>>>=20 >>>>>>>>>>> The benefit will be obviously that the new rules (if >>>>>>>>>>> accepted) may llead to a better overall communication=20 >>>>>>>>>>> characteristics. >>>>>>>>>>>=20 >>>>>>>>>>> /yuri >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> =3D> I'm trying to understand what you mean above. These are = >>>>>>>>>>> all scenarios, the question is: What is the benefit for the=20 >>>>>>>>>>> HA to transfer rules? The HA will not know the path between=20 >>>>>>>>>>> the MN and CN more than either node does. So I don't=20 >>>>>>>>>>> understand what _benefits_ you see here. >>>>>>>>>>>=20 >>>>>>>>>>> Hesham >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Pretty much sure that there are more examples and I=20 >>>>>>>>>>>> encourage to think about those not from MN point of view=20 >>>>>>>>>>>> but rather from the HA service provider. >>>>>>>>>>>>=20 >>>>>>>>>>>> /yuri >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>>>>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>>>>> Cc: mext@ietf.org >>>>>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>>>>> directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Yuri, >>>>>>>>>>>>=20 >>>>>>>>>>>> It is just rules TRANSFER which is the matter of MIP. So=20 >>>>>>>>>>>> where is the logic when saying that MN to HA rules transfer = >>>>>>>>>>>> is a practical engineering and HA to MN is an academic=20 >>>>>>>>>>>> interest? >>>>>>>>>>>>=20 >>>>>>>>>>>> =3D> I think we've (I'm including myself) highlighted = several=20 >>>>>>>>>>>> reasons for why it makes little sense to transfer rules=20 >>>>>>>>>>>> from HA to MN. >>>>>>>>>>>> Instead of rat-holing on theory Vs practice, you (or others = >>>>>>>>>>>> advocating the other direction) need to come up with=20 >>>>>>>>>>>> reasons for doing things this way. This way we can think=20 >>>>>>>>>>>> like engineers about tradeoffs. >>>>>>>>>>>> Absent that, I don't see any point in having theory Vs=20 >>>>>>>>>>>> practice high level discussions, which will lead nowhere. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards >>>>>>>>>>>> Yuri >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>>>>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>>>>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>>>>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>>>>> directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi Pierrick, >>>>>>>>>>>>=20 >>>>>>>>>>>> On Jun 2, 2009, at 4:11 PM,=20 >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>> Please see inline comment. >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>> Pierrick >>>>>>>>>>>>=20 >>>>>>>>>>>> ________________________________________ >>>>>>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>>> De la part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 = 09:35 =C0 : >>>>>>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important=20 >>>>>>>>>>>> considerations for directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham, >>>>>>>>>>>> This is nice story and makes some sense for the discssion,=20 >>>>>>>>>>>> however some details are ommited. In your adventure with=20 >>>>>>>>>>>> the helpdesk, it (the >>>>>>>>>>>> helpdesk) is a third party service and thus your=20 >>>>>>>>>>>> conclusions make sence. >>>>>>>>>>>> Think of the situation when superior of a heldesk person=20 >>>>>>>>>>>> will tell him/her to check access point in some room. Would = >>>>>>>>>>>> it be the same reaction? I assume not. By that I mean that=20 >>>>>>>>>>>> if, for example, I'll install home agent in my home=20 >>>>>>>>>>>> network, I can make it know anything I want about MN, and=20 >>>>>>>>>>>> more intresting is that how I will do it, does not require=20 >>>>>>>>>>>> any standardization. >>>>>>>>>>>> In other words, I'm superior of my HA. >>>>>>>>>>>> This situation is not unthinkable, I personally believe=20 >>>>>>>>>>>> that this is much more efficient way of using HA=20 >>>>>>>>>>>> fnctionality as opposed to big service providers who will=20 >>>>>>>>>>>> have to fight with scalability and performance. >>>>>>>>>>>> However, one does not exclude another. >>>>>>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> The difference between policy and rules is not only a=20 >>>>>>>>>>>> matter of conversion. A policy, is a static, or=20 >>>>>>>>>>>> quasi-static, set of guidance for the MN (e.g use access=20 >>>>>>>>>>>> network X for application type >>>>>>>>>>>> A,...) while a rule update requires to be more dynamic. I = mean: >>>>>>>>>>>> eventually a policy could be updated depending on network=20 >>>>>>>>>>>> condition (e.g if X overloaded, use access network Y for=20 >>>>>>>>>>>> application type A,...) but a rule reacts on local triggers = (e.g. >>>>>>>>>>>> modification of the radio link >>>>>>>>>>>> quality) with a shorter period of variation. So, IMHO,=20 >>>>>>>>>>>> there is no requirement for updating policy on a short=20 >>>>>>>>>>>> period and out-of-band mechanism can be used (e.g. IEEE >>>>>>>>>>>> 802.21 in push mode,...). >>>>>>>>>>>>=20 >>>>>>>>>>>> Fully agree! >>>>>>>>>>>> This is why I do not support the exchange of rules from the = >>>>>>>>>>>> HA to the MN. >>>>>>>>>>>> Policies may be exchanged from the HA to the MN, but MIP is = >>>>>>>>>>>> definitely not the protocol to transport them. >>>>>>>>>>>>=20 >>>>>>>>>>>> Nicolas >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> My 2 cents... >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Is there any reason to restrict where such convertion takes = place? >>>>>>>>>>>> True >>>>>>>>>>>> that a HA does not know what is going on in the access=20 >>>>>>>>>>>> network, on the other hand HA may know what is the network=20 >>>>>>>>>>>> condition between HA and correspondent node. Either of this = >>>>>>>>>>>> information is important, if not equally important. >>>>>>>>>>>> It is not really difficult to let an MN to reject rules=20 >>>>>>>>>>>> sent by HA, which in my view would be quite natural. This=20 >>>>>>>>>>>> implies that HA must follow the rules installed by MN until = >>>>>>>>>>>> explicit acceptance has been received from MN. >>>>>>>>>>>> Such procedure is very similar to an MN beahviour when=20 >>>>>>>>>>>> initiating new BU, where MN is not supposed to send any=20 >>>>>>>>>>>> traffic before BU confirmation. >>>>>>>>>>>> BTW, what is the numerical representation of "rough = consensus"? >>>>>>>>>>>> I assume is when majority is for, is it so? >>>>>>>>>>>> Yuri >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>>> On Behalf Of Hesham Soliman >>>>>>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>>>>>> To: mext >>>>>>>>>>>> Subject: [MEXT] Important considerations for directionality = >>>>>>>>>>>> of flow bindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>> I've always been a fan of the IETF's tradition of rough=20 >>>>>>>>>>>> concensus (as opposed to voting). To me, this implies that=20 >>>>>>>>>>>> you need to get your point across and get other people to=20 >>>>>>>>>>>> see that point of view. >>>>>>>>>>>> As opposed to other organisations that require their=20 >>>>>>>>>>>> members to vote and end up with rigid political positions. >>>>>>>>>>>>=20 >>>>>>>>>>>> The chairs asked us about the directionality question of=20 >>>>>>>>>>>> the flows bindings. >>>>>>>>>>>> On the charter question, I said that the charter doesn't=20 >>>>>>>>>>>> need to mention how a solution should work, but rather what = >>>>>>>>>>>> problem needs to be solved. >>>>>>>>>>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>>>>>>>>>> transferring rules "between" the MN and HA without=20 >>>>>>>>>>>> mentioning directions. >>>>>>>>>>>>=20 >>>>>>>>>>>> Nevertheless, we still need to agree on identifying the=20 >>>>>>>>>>>> requirement for the solution. And when it comes to this,=20 >>>>>>>>>>>> I'm strongly against voting and I'll practice this by=20 >>>>>>>>>>>> explaining in this email why I think rules can not be=20 >>>>>>>>>>>> transferred from the HA to the MN and that the only=20 >>>>>>>>>>>> direction that makes sense in MIP is >>>>>>>>>>>> MN->HA. I'll deliberately ignore arguments like "some=20 >>>>>>>>>>>> MN->people want >>>>>>>>>>>> this" or "an SDO wants this". They fall under the=20 >>>>>>>>>>>> "meaningless words" >>>>>>>>>>>> category and I'm incapable of discussing them because they=20 >>>>>>>>>>>> come with voting attitudes. They all need to be justified=20 >>>>>>>>>>>> if the WG wants to have a technical _discussion_. >>>>>>>>>>>>=20 >>>>>>>>>>>> Here are my reasons: >>>>>>>>>>>>=20 >>>>>>>>>>>> 1. The HA does not know whether a CoA is tied to a certain=20 >>>>>>>>>>>> access technology. It is one thing for the HA to send a=20 >>>>>>>>>>>> message saying "forward port 80 traffic on a wifi link" (a >>>>>>>>>>>> policy) and a completely different thing to say "forward=20 >>>>>>>>>>>> port 80 traffic using CoA 3ffe::1" >>>>>>>>>>>> (a rule). >>>>>>>>>>>>=20 >>>>>>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem = now? >>>>>>>>>>>> The problem is that the HA has no idea about dynamic=20 >>>>>>>>>>>> changes on that wifi link. It doesn't know if it's=20 >>>>>>>>>>>> congested, it doesn't know what application is using port=20 >>>>>>>>>>>> 80 (it doesn't have to be web >>>>>>>>>>>> traffic) or port 8000 for that matter and doesn't even know = >>>>>>>>>>>> if the AP of that wifi link works at all. >>>>>>>>>>>> Finally, it >>>>>>>>>>>> doesn't know the user's policies or other admin policies=20 >>>>>>>>>>>> for that MN. >>>>>>>>>>>> This type of information needs to be sent regularly because = >>>>>>>>>>>> it changes all the time and requires serious cross layer=20 >>>>>>>>>>>> integration including sometimes layer 8 integration! It's=20 >>>>>>>>>>>> completely impractical. >>>>>>>>>>>>=20 >>>>>>>>>>>> 3. If the HA installed rules in the MN, what happens if the = >>>>>>>>>>>> MN wants to change those rules. Say the wifi link went=20 >>>>>>>>>>>> down, or the MN's wifi interface went down and it wants to=20 >>>>>>>>>>>> move that traffic to another interface. Would the HA reject = >>>>>>>>>>>> such move? >>>>>>>>>>>> Does the MN have to justify to the HA why it needs to move=20 >>>>>>>>>>>> traffic? Does that involve writing a letter perhaps? >>>>>>>>>>>> If you say "well in that case, the HA should let the MN=20 >>>>>>>>>>>> move the traffic" >>>>>>>>>>>> then I'll ask you: what's the point of having the HA=20 >>>>>>>>>>>> install this stuff if it has no authority and how does it=20 >>>>>>>>>>>> know the reason for the MN's movement of the flow? >>>>>>>>>>>> The way to control how users do things is to incentivise=20 >>>>>>>>>>>> them with charging models and show them that things work=20 >>>>>>>>>>>> better on certain technologies, not by installing rules=20 >>>>>>>>>>>> that can't be followed. It's a broken mindset and we've=20 >>>>>>>>>>>> known that it's broken for a long time. >>>>>>>>>>>>=20 >>>>>>>>>>>> 4. Some people mentioned that the HA should be able to=20 >>>>>>>>>>>> revoke flows on the MN. I'm perfectly fine with that, just=20 >>>>>>>>>>>> extend the binding revocation draft to handle flows and the = >>>>>>>>>>>> rest is pretty straight forward. >>>>>>>>>>>>=20 >>>>>>>>>>>> Finally, I'll indulge in a true story that happened to me a = >>>>>>>>>>>> few years ago when I found that my wifi link wasn't working = >>>>>>>>>>>> in a hotel (no >>>>>>>>>>>> radio) >>>>>>>>>>>> and called the help desk. He insisted that the link was up=20 >>>>>>>>>>>> an I insisted that it wasn't. When I asked him to tell me=20 >>>>>>>>>>>> how he knows the link is up he said: I can ping the AP! Of=20 >>>>>>>>>>>> course after another >>>>>>>>>>>> 5 minutes of trying to convince him that pinging the AP=20 >>>>>>>>>>>> doesn't mean the radio is actually working he sent someone=20 >>>>>>>>>>>> to the hotel who in turn realised that the radio was not = working. >>>>>>>>>>>> For those people who want rules to be transferred from the=20 >>>>>>>>>>>> HA to the MN, please think of your HA as this help desk=20 >>>>>>>>>>>> person, i.e. >>>>>>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>>>>>=20 >>>>>>>>>>>> I hope this helps with the realisation that decisions can't = >>>>>>>>>>>> be made here based on voting and that there is little merit = >>>>>>>>>>>> to transferring rules from the HA to the MN. Policies can=20 >>>>>>>>>>>> be transferred without any problems, but not rules. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From mer@kafka.verkstad.net Tue Jun 9 01:24:01 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97963A6827 for ; Tue, 9 Jun 2009 01:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 E-f-rGuTWBSu for ; Tue, 9 Jun 2009 01:24:01 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id CC51D3A6806 for ; Tue, 9 Jun 2009 01:24:00 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id AB3EE710A8C; Tue, 9 Jun 2009 10:24:05 +0200 (CEST) Date: Tue, 9 Jun 2009 10:24:05 +0200 From: Michael Eriksson To: mext@ietf.org Message-ID: <20090609082405.GA9874@kafka.verkstad.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [MEXT] Flow rules directionality X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 08:24:02 -0000 I think that the discussion regarding flow rules directionality is somewhat awry, and not as open as it could be... Here are some comments regarding three arguments that are used in the discussion. 1. "Only the MN knows enough to construct the flow rules" The truth is that the knowledge is spread between the HA and the MN. Some cases where the HA knows more than the MN: - It has access network information. A typical case is an HA that is also a 3GPP GGSN/PDN-GW. - Some applications are implemented in an operator's service network. All the application logic is in the network, and the MN only contains a "thin" client. The HA will have "out-of-band" communication with the server in the service network. In practice, some information must be transmitted between the MN and HA to make good flow rules. But why would that information have to be transmitted as "high-level policies" from the HA to the MN? In some cases, it could be better for the MN to transmit its information to the HA, which would then do all the decision making (i.e., rule generation). This would simplify the MN, which is a good thing in some scenarios (say cost reduced mobile phones). Some terminals (operator branded mobile phones?) may only contain clients for applications in the operator services network, and then the HA will know about all flows and the MN will not have to send any information before rule generation. The HA can look in the binding cache to see what interfaces work on the MN. 2. "The HA can't know what access is used for a particular CoA" The MN and HA must have a prior agreement on what BIDs the MN should use, but that is trivial. For example, the MN always uses BID 10 for its HSPA interface and BID 11 for its WiFi interface. 3. "There is no reasonable use case for HA -> MN rule transfer" This argument is plain silly, IMHO. Obviously, people see a need to send rules from HA to MN. Choosing a solution with artificial limitations just because some vocal people don't want some reasonable functionality is not very impressive... But this is really a non-issue: Just read the working group charter. The rule transfer shall be bidirectional. If anyone wants to recharter (at this late moment), that is a separate discussion. Regards, Michael From hesham@elevatemobile.com Tue Jun 9 01:33:07 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2108A28C197 for ; Tue, 9 Jun 2009 01:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] 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 x5LM4PjCcbMS for ; Tue, 9 Jun 2009 01:33:03 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 4347628C17D for ; Tue, 9 Jun 2009 01:33:01 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MDwlI-0000u9-HQ; Tue, 09 Jun 2009 18:32:56 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 09 Jun 2009 18:32:44 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkM In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 08:33:07 -0000 >> First, is that we have agreed already that we are talking about interfac= es. >> Yes, we are talking about interfaces configured with CoA. Interfaces >> configured with HoA does not give any information about >> characteristices of interfaces configured with CoA, thus choosing HoA >> or HA can not provide any meaningful information about access >> characteristics. Thus it is not clear at all where from comes idea about >> relevance to HA selection. >=20 > =3D> The hints that you were suggesting that the HA sends are only relevant= to > HoA selection. Do you agree? > No, I explained above why. HoA selection is meaningless in general becaus= e > does not provide any usable information for selection of interfaces. =3D> Sigh..Yuri, we agree on that. But then you still think that HA hints somehow magically give information to the MN about its interfaces so it knows better what to choose. >=20 >> In all my examples (e.g. the latest one about broadband operators) it >> does not matter which HA (HoA) is used. All what matters is which >> access MN uses and if there was traffic shaping policy applied to that a= ccess >> by an access provider. >> We have agreed that MN can not know about the later. HA can. >=20 > =3D> No! You were talking about traffic shaping by the HA or its upstream I= SP. > What do you mean by "provider" above? Where is the traffic being impacted= ? > I'm not aware of any HA installed by any of access providers at the momen= t > (any information about that would be highly appreciated). Traffic shaping= , on > the other hand, is applied in reality by some access providers, which hav= e a > quota on the amount of traffic sent within a period of time, typically ov= er a > month. > By provider I mean any provider who offers connectctivity to global Inter= net. > A provider can offer such connectivity over single access technology or > multiple different access technologies =3D> So where is the traffic shaping done in your scenario? Before you said i= t was upstream from the HA, which led me to the answers I gave earlier. Now where is it done in this discussion? FWIW, if it's done by the HA or upstream from the HA it's completely irrelevant to this discussion. >=20 >>=20 >> Second, is that we are talking about sending rules from HA to MN. I >> call these rules hints, because and only because in my view MN should >> have rights to ignore the rules from HA. Both transportwise and >> contentwise, we are still talking about rules. At the moment I do not >> see any specific need for specific types of hints. >=20 > =3D> If we're talking about CoA selection I don't see any relevance to thos= e > hints. The only way you can show there is relevance is by providing an > example. The example you provided had no relevance to CoA selection. I do= n't > understand why we need to go back two emails again. If you still think yo= ur > scenario had relevance to CoA selection then please respond to my earlier > response to your scenario. >=20 > Here I call you to read my emails as well. I explained that CoA selection= is > the result of interface selection. We are talking about selecting interfa= ces > based on their characteristics for particular flows. Information about > downgrading the link performance is relevant to the communication > charachteristics of flows sent through that interface. =3D> Relevant to who??? It's relevant to the MN and is known by the MN. How does the HA fit in here? >=20 >>=20 >> Information about the fact that up/down link from/to HA for a >> particular interface was downgraded is very relevant for MN because >> based on this information MN can select another interface for some of >> its flows and make correspondent move. > =3D> Are you saying the MN will notify the HA everytime I do this: > Ifdown eth1: ifup eth1 >=20 > Why on earth would you do that? > If you had flows running on eth1 before you have performed "ifdown eth1" = and > you want this flows to continue, you apperantly should move flows to anot= her > interface. If the current rule set in the MN changes, then the rule set i= n the > HA has to be synchronized with what MN has generated due to "ifdown eth1" > event. =3D> Yes we do that with the BU, I still don't see what the HA->MN does here. >=20 > If this is not the case then what is the objactive of >> interfaces selection? If better choice of interface for applications >> is not an objective then why bother about flow mobility at all? >=20 > =3D> I don't understand what you're saying Yuri. Please respond to my earli= er > email which responded to your scenario. I can't see how you still think t= hat > the HA can influence CoA selection. >=20 > The HA is sending the rules where particlar flow(s) are suggested to move= to > another interface. =3D> Well, as I said, at least a dozen times, there is zero information available to the HA to make this suggestion. So unless you provide concrete information to transfer I really can't see any point in this proposal. Hesham >=20 > /yuri > Hesham >=20 >>=20 >> Regards >> Yuri >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Monday, June 08, 2009 4:29 PM >> To: Yuri Ismailov; Nicolas Montavont; >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of >> flowbindings >>=20 >>=20 >>=20 >>=20 >> On 9/06/09 12:12 AM, "Yuri Ismailov" wrote: >>=20 >>> =20 >>> =3D> Yes but I still think you're talking about something else. The >>> interface you're talking about seems to be associated with the HoA. >>> This is the only case where I can see the relevance of HA hints (not >>> rules). The interfaces I'm talking about and discussed in the context >>> of flow bindings are those associated with CoAs. There is nothing >>> coming from the HA about its links ...etc that can have any impact on >>> CoA selection. >>>=20 >>> Hesham >>> here I tend to agree. I actually ment interfaces with CoA, but now >>> realized that in such configuration, where each of interfaces has >>> it's own HA configured, it is most likely that each of interfaces >>> will have different HoA. >>> Once this is the case then moving a flow between those interfaces >>> will lead to change of HoA. As we are in MIP context, I would better >>> avoid that. In the whole discussion I mean interafces with CoA >>> because selection of HoA and/or associated to it interface can not be >>> based on physical characteristics of that interface. >>=20 >> =3D> Sounds fine to me. >>=20 >>>=20 >>> So the valid and meaningful scenario is moving flow(s) between >>> interfaces associated with the same HA, whether all interfaces of the >>> MN or some of them will be configured this way does not really matter. >>>=20 >>> Fine with me. Should we finalize then? As I see it, once there is a >>> meaningful information, which can be sent in HA -> MN direction, then >>> MN can use it for re-evaluting policies and producing the new set of >>> rules. Definetely not at all times new rules will be produced, they >>> may stay unchanged, as it will be the case with many other events >>> taking place at either side: MN or HA. >>>=20 >>> Is that correct? >>=20 >> =3D> So now that we agree that we are only talking about CoAs then I >> don't see any meaningful information coming from the HA. Hints about >> upstream routing changes ...etc are relevant to HoA selection (even if >> the HoA is not tied to a physical interface it doesn't matter). This >> is an interesting problem to discuss but I want to be clear on its conte= xt. >> So to summarise my opinion: >> HA-> MN hints (not rules) may be relevant for intial HoA selection for >> certain connections. The types of hints and how to formulate this in a >> global manner can lead to interesting work (although it's a complex prob= lem). >> However, this information is not in anyway relevant to CoA/physical >> interface selection on the MN. >>=20 >> Hesham >>=20 >>=20 >>>=20 >>> Regards >>> Yuri >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Monday, June 08, 2009 2:00 PM >>> To: Yuri Ismailov; Nicolas Montavont; >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of >>> flowbindings >>>=20 >>> Yuri, >>>=20 >>> I think we're getting close here. >>>=20 >>>=20 >>> On 8/06/09 6:29 PM, "Yuri Ismailov" wrote: >>>=20 >>>> Hesham, It looks like that the only point of disagreement is about >>>> changing HA and mapping between HA and access. >>>> Some explanations of what I mean below: >>>>=20 >>>>=20 >>>> 1. Changing HA. >>>> As it follows from group charter change of HA is in the plans of >>>> MEXT WG. I assume that this is going to be a separate work item >>>> because the reason specified for that is very specific and relates >>>> to deployment more than to flow mobility. Do not want to speculate, >>>> about this right now but the change of HA does not necessarily means >>>> change of rules. >>>> So the proposal is to not to discuss change of HA as you suggested. >>>=20 >>> =3D> Agreed. >>>=20 >>>>=20 >>>> 2. In my example I do not mean change of HA as an explicit procedure >>>> specified separately. One confirmation to that is that single HA for >>>> all interfaces is included and valid option. Based on the HA -> MN >>>> exchange, the MN may perform interface selection procedure and may >>>> choose another interface for some flow(s). In multiple HA case it >>>> will result of the rules update MN -> HA to the HA which is relevant >>>> for the new interface chosen for flows. Please notice, There is >>>> nothing about HA change, only about interface selection. >>>=20 >>> =3D> Yes but I still think you're talking about something else. The >>> interface you're talking about seems to be associated with the HoA. >>> This is the only case where I can see the relevance of HA hints (not >>> rules). The interfaces I'm talking about and discussed in the context >>> of flow bindings are those associated with CoAs. There is nothing >>> coming from the HA about its links ...etc that can have any impact on >>> CoA selection. >>>=20 >>>>=20 >>>> 3. I do not map HA and access. It is allowed for any access provider >>>> to offer HA service and once this is the case it will be so. Thus an >>>> MN can have multiple HA configured for the use on different interfaces= . >>>=20 >>> =3D> Good, we agree on that too. >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> Regards >>>> Yuri >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Friday, June 05, 2009 4:18 PM >>>> To: Yuri Ismailov; Nicolas Montavont; >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of >>>> flowbindings >>>>=20 >>>>=20 >>>>=20 >>>>> First is that I assume that we have simulteneous multiaccess in >>>>> mind, i.e. MN has more than one interface to choose from for its >>>>> flows. If this is not the case then I will stop the discussion. >>>>> This assumption is based on the fact that we are (I hope at least) >>>>> discussing flow mobility. >>>>=20 >>>> =3D> Sure. >>>>=20 >>>>>=20 >>>>> Secondly, I consider that MN chooses an interface but not CoA. I >>>>> gave a though about that and did not come up with any information >>>>> which can be derived from CoA in order to choose it. An interface >>>>> has at least expected characteristics, thus can be a subject of >>>>> choice. Any clarification about that would be appreciated. >>>> =3D> An application would choose an interface, but of course the IP >>>> stack selects the corresponding address. I'm sure there is no >>>> disagreement there. >>>>=20 >>>>>=20 >>>>> Next assumptions are about possible configurations of HA >>>>> - Single HA for all interfaces configured in the mobile. HA can >>>>> belong to any of the access providers of each of access technology >>>>> used by MN. >>>>=20 >>>> =3D> Ok. >>>>=20 >>>>>=20 >>>>> - One HA per access or set of accesses, which is subset of all >>>>> access techologies presented or potentially may be presented >>>>> (detached >>>>> devices) in MN. >>>>=20 >>>> =3D> Now you're getting into a different problem space from flow mobilit= y. >>>> This is why I wanted you to break the scenario down. We are not >>>> dealing with multiple HoAs in this work item, we're dealing with >>>> multiple CoAs, i.e. One HoA. >>>>=20 >>>>> Anticipating numerous questions about that can say that I looked at >>>>> such configuration and did not find anything strange with it, i.e. >>>>> (1) it works, >>>>> (2) it does not require any change to MIP or any other of its >>>>> extensions. (3) Configuration is performed per interface and does >>>>> not introduce any ambiguities. (4) it is natural for access >>>>> provider to offer HA service. >>>>=20 >>>> =3D> Yes of course it works but as I read this I'm guessing that you >>>> want the MN to change HoA. This is not the problem we're discussing >>>> in this WG. >>>> Another issue, I'm not comfortable with the wording of "HA per access" >>>> because they're not tied to access. Let's just say there are >>>> multiple Has and not associate it with an access. >>>>=20 >>>>>=20 >>>>> - "Residential" HA. Assumption is that it can be either one of HA's >>>>> or a single HA for all types of accesses. This is the matter of MN >>>>> configuration. >>>>> "Residential". >>>>=20 >>>> =3D> Please don't tie HA to access. >>>>=20 >>>>>=20 >>>>> - Any HA may have multiple interfaces, e.g. "residential" HA may be >>>>> connected to mobile broadband, DSL, etc. >>>>=20 >>>> =3D> sure >>>>=20 >>>>>=20 >>>>> Next assumption comes from the example (e.g. latest one) >>>>> - Traffic shaping is applied in both directions (up/down) link (in >>>>> practice this is the case). >>>>> - Traffic shaping (TS) is applied to user subscription. In other >>>>> words TS is applied to packets belonging to a particular >>>>> subscription but not to an aggregated traffic on gateway interfaces. >>>>> HA is not necessary (however, nothing prevents from that) a gateway >>>>> where TS is applied. >>>>>=20 >>>>>=20 >>>>> I hope that I have not missed something, although it may be possible. >>>>> If we can agree on that or correct if something is wrong here and >>>>> agree later then we know how to proceed further on >>>>=20 >>>> =3D> Your scenario is fine (with the wording changes for tying Has to >>>> access). >>>> But I want to pre-empt any suggestion that the HA will tell the MN >>>> to use a different HoA. This is very possible but it's not the >>>> problem being discussed here. It may well be something for charter >>>> discussion but it has zero impact on flow bindings for multiple CoAs. >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> /yuri >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: Friday, June 05, 2009 11:37 AM >>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>> pierrick.seite@orange-ftgroup.com >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of >>>>> flowbindings >>>>>=20 >>>>> Yuri, >>>>>=20 >>>>>=20 >>>>>> Still not clear for me why you call scenarious invalid? >>>>>> Some broadband providers (this is used in practice) have quota on >>>>>> the amount of traffic sent by users. Once quota is exceeded >>>>>> provider downgardes outgoing traffic from its network to 64Kbs >>>>>> (this figure is the real example from real provider). Such >>>>>> combination of to paths, where one is high speed, lets say 10 Mbs >>>>>> and another one is 64Kbs is quite crusual to apps running on top of = TCP. >>>>>> Not for all types of traffic though. >>>>>=20 >>>>> =3D> Yes I know the scenario but I keep saying to you that the change >>>>> in upstream routing in the HA has nothing to do with CoA selection >>>>> by the MN in the visited network. If anything, you want the MN to >>>>> change it's HoA depending on how the switch to another upstream ISP w= orks. >>>>> It's a completely irrelevant issue to this discussion. Do you agree? >>>>> If not why not? I really want to see an answer to this point. >>>>>=20 >>>>> =20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> MN can not know about this situation. Nobody will send this >>>>>> information to MN. >>>>>=20 >>>>> =3D> Yes and if it knows what will it do??? If you can answer that >>>>> you will fix the deadlock we have. >>>>>=20 >>>>>> That means that MN will choose its interfaces based on its >>>>>> knowledge about 10Mbs link capabilities. >>>>>=20 >>>>> =3D> You're talking about two different things. The MN doesn't choose >>>>> the HA's outgoing interface! What am I missing? >>>>>=20 >>>>> Obtaining this isnformation from HA is quite >>>>>> significant to make a better decision about choice of interfaces >>>>>> for its flows. >>>>>> This is concrete example of what happens in the reality. >>>>>> Do you consider that this information will be useless for MN? >>>>>=20 >>>>> =3D> Completely useless. Unless I'm missing something in your scenario. >>>>> Just write down step by step what will happen and include messages. >>>>> I don't see how this can possibly be relevant to the MN. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>>=20 >>>>>> /yuri >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>> Sent: Thursday, June 04, 2009 4:38 PM >>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>> pierrick.seite@orange-ftgroup.com >>>>>> Cc: mext@ietf.org >>>>>> Subject: Re: [MEXT] Important considerations for directionality of >>>>>> flowbindings >>>>>>=20 >>>>>> Yuri, >>>>>>=20 >>>>>>=20 >>>>>> On 5/06/09 12:01 AM, "Yuri Ismailov" wr= ote: >>>>>>=20 >>>>>>> Hesham, >>>>>>>=20 >>>>>>> I provided several scenarious which you said are invalid. This is >>>>>>> where my conclusion about standpoint comes from. >>>>>>> Whether you call hints policies or rules it does not change what >>>>>>> information can be provided by HA to MN. >>>>>>=20 >>>>>> =3D> It changes the outcome for the work item we're discussing. I'm >>>>>> trying to come to a conclusion on this and there is a huge >>>>>> difference between transferring policies and installing flow binding= s. >>>>>>=20 >>>>>>> By sending rules HA does not install anything in MN. Likewise, MN >>>>>>> does not install rules in HA, it informs HA about currently made >>>>>>> choices. >>>>>>> As I remember rules will not be valid until proper Ack arrival, >>>>>>> which for me means that may not be instantiated at all. >>>>>>> Niether rules nor polices are specific to MIP. As I wrote those >>>>>>> can be exchanged between hosts without any MIP implementation, >>>>>>> just for access selection purposes. Once it was decided to make >>>>>>> it as part of MIP protocol, I'm fine with that. Do not have any >>>>>>> idea to discuss this, while personally consider that the work on >>>>>>> rules transfer can very well fit into the MEXT group but as a >>>>>>> separate work item, but this is not the case now, so good enough th= e way >>>>>>> it is. >>>>>>> And back again, it really gets repeated, so will lead to nowhere, >>>>>>> you've got my arguments and tell that the information, which I'm >>>>>>> talking about, is not usefull. What can I say more? I can put you >>>>>>> on my position and start asking questions instead of answering. >>>>>>> So, why it is not usefull? >>>>>>=20 >>>>>> =3D> I explained why the specific information you mentioned was not >>>>>> useful/useable by the MN and this is what I referred to as unanswere= d. >>>>>> Because if you agree with my previous explanations then we don't >>>>>> need to discuss it further. If you disagree you certainly didn't >>>>>> tell me why. You have the charge of proof because you want to >>>>>> change the way MIP works currently, that's all I'm trying to say. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>>=20 >>>>>>> /yuri >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>> Sent: Thursday, June 04, 2009 4:00 AM >>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>> Cc: mext@ietf.org >>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>> of flowbindings >>>>>>>=20 >>>>>>> Yuri, >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> Missing is additional information which may be helpful in making >>>>>>>> better decision about interface selection by MN. >>>>>>>> Which information is that I wrote in my previous emails. Back to >>>>>>>> my examples (not all, do not want to repeat myself). If HA will >>>>>>>> have changed traffic shaping parameters on one of the incoming >>>>>>>> or outgoing interfaces, this will be important information for MN = to >>>>>>>> know. >>>>>>>> We have agreed already that whether this information important >>>>>>>> or not, benfitial or not is a matter of standpoint. >>>>>>>=20 >>>>>>> =3D> I don't agree or like to think that it's a matter of standpoint. >>>>>>> That's why I asked you on every point you raised and compared >>>>>>> this to the MN's knowledge on e2e basis. Once we have "standpoints" >>>>>>> then we're getting outside the technical realm. The reason I >>>>>>> don't think it's useful is that this information cannot be used >>>>>>> by the MN to select a CoA. I've already stated that before and >>>>>>> you seemed to agree so I don't know why you repeat this as a >>>>>>> reason for the HA to install filters in the MN. Let me say it >>>>>>> again: There is no correlation between the routing on the HA's >>>>>>> upstream interfaces/ISP with the MN's selection of a CoA. >>>>>>>=20 >>>>>>>> I consider that knowing more is a benefit and will help to get >>>>>>>> better result. >>>>>>>>=20 >>>>>>>> My point is still the same. I see the reverse rules sending as >>>>>>>> possibility to provide more information to the MN, thus make MN >>>>>>>> to get to better decision about interface selection for its flows. >>>>>>>> This point has not changed since the beginning of the discussion. >>>>>>>=20 >>>>>>> =3D> This is why we're not making progress IMO: >>>>>>>=20 >>>>>>> 1. The hints you refer to are not the same things as installing >>>>>>> rules on the MN. Completely different information in fact. You've >>>>>>> essentially proved that when you suggested that the MN can accept >>>>>>> or reject them. So, let's not call them rules. The more direct >>>>>>> word for what you want to send is policies >>>>>>>=20 >>>>>>> 2. You didn't provide a valid scenario that we can discuss as to >>>>>>> why it's needed or how it could work. I've asked numerous >>>>>>> questions in each email that were not answered (with the >>>>>>> exception of the last email). It's not possible to progress the >>>>>>> discussion without answering each others' >>>>>>> questions. You can go back through the threads and verify this. >>>>>>>=20 >>>>>>> 3. If we're sending rules from the HA to the MN and the MN can >>>>>>> reject those rules then the whole exercise is pointless. You >>>>>>> really want to send policies not rules. I can imagine those >>>>>>> policies being one of the inputs that the MN uses to make a >>>>>>> decision. I still fail to see how anything happening on the HA's >>>>>>> upstream interfaces/ISP link can possibly influence the MN's >>>>>>> decision for CoA selection. >>>>>>> This is another unanswered question. >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>>=20 >>>>>>>> /yuri >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>> Sent: Wednesday, June 03, 2009 4:09 PM >>>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>> Cc: mext@ietf.org >>>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>>> of flowbindings >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 3/06/09 10:47 PM, "Yuri Ismailov" >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> Ok, see your point, however:-) >>>>>>>>>=20 >>>>>>>>> The major difference here is that your are talking about CoA >>>>>>>>> selection and I'm talking about interface selection. Quite a >>>>>>>>> big difference. >>>>>>>>=20 >>>>>>>> =3D> No, that's not the point really. The point is that there is >>>>>>>> no relationship between CoA/interface selection on the MN and >>>>>>>> the upstream ISP for the home network. >>>>>>>>=20 >>>>>>>>> I do not see any grounds for MN to select CoA, based on what? >>>>>>>>> Prefix length? >>>>>>>>> While selection of an interface is based on expected >>>>>>>>> characteristics of the communication. Routes (up/down)link in >>>>>>>>> my opinion do have impact on the characteristics and this is >>>>>>>>> exactly the information missing in the MN when selecting interfac= e. >>>>>>>>=20 >>>>>>>> =3D> There is nothing missing for the MN to make this selection. >>>>>>>> Please tell us specifically what is missing. You're changing >>>>>>>> points on me all the time now. >>>>>>>> Lets stick to one point at a time. What's missing? >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Whenever, MN decides to move a flow, the reason can be anything >>>>>>>>> but not which CoA it has configured on each interface. >>>>>>>>>=20 >>>>>>>>> Another thing is that MN will notice something e2e if and only >>>>>>>>> if such support is implemented in the MN. >>>>>>>>=20 >>>>>>>> =3D> Of course, so what? >>>>>>>>=20 >>>>>>>> Moreover, this notice can not be made at IP layer. >>>>>>>>> TCP fights alone with all problems and never tells to any other >>>>>>>>> layer what is going on. So what is left? Two options. Add this >>>>>>>>> support to operating system, which makes its (support) >>>>>>>>> existence questionable, or to applications, which is even more >>>>>>>>> questionable. >>>>>>>>=20 >>>>>>>> =3D> It's interesting that you think it's questionable to add the >>>>>>>> support to the MN's OS but not questionable to add the support >>>>>>>> to the HA's OS, which will not lead to the same reliability as >>>>>>>> if it were done in the MN. It doesn't make sense to me. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Well, that's debatable, but this is clearly not a reason to >>>>>>>>>>> do anything. >>>>>>>>>>>=20 >>>>>>>>> Are you serious about that MIP may be broken because of that? >>>>>>>>=20 >>>>>>>> =3D> Yes! It's not designed to do what you want to do. Luckily, in >>>>>>>> this case what you want, IMO, is broken anyway so it's not a probl= em. >>>>>>>>=20 >>>>>>>> Hesham >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> /yuri >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>> Sent: Wednesday, June 03, 2009 1:15 PM >>>>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>> Cc: mext@ietf.org >>>>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>>>> of flowbindings >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Still some answers, despite knowing that in your opinion they >>>>>>>>>> are not benefits. >>>>>>>>>>=20 >>>>>>>>>> First of all MIP will not be breaked if the rules will be sent >>>>>>>>>> in both directions. >>>>>>>>>=20 >>>>>>>>> =3D> Well, that's debatable, but this is clearly not a reason to >>>>>>>>> do anything. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> - Access provider preferences relate to the use of backbone >>>>>>>>>> provider, which may vary with the time of day. Changing >>>>>>>>>> backbone provider can make quite big difference for >>>>>>>>>> commnication between HA (if HA service is provided by the same >>>>>>>>>> access >>>>>>>>>> provider) and CN(s). >>>>>>>>>> The difference can be expressed in, let's say, number of hops, >>>>>>>>>> load, possibly something else. Such change is an event and may >>>>>>>>>> have an impact on the overall communication. This can be told >>>>>>>>>> directly to MN or HA. Direct communication to MN (if accepted >>>>>>>>>> as >>>>>>>>>> benefit:-)) in such case will need standardization. >>>>>>>>>> Communication of this information to HA does not (I consider >>>>>>>>>> this as a benefit). >>>>>>>>>> HA may act upon that event, and the rest you >>>>>>>>>> know: rules in reverse direction. >>>>>>>>>=20 >>>>>>>>> =3D> There is no need to _tell_ the MN anything. There are two >>>>>>>>> issues here. >>>>>>>>> First, changing network conditions are best known e2e. So the >>>>>>>>> MN will know that anyway based on the traffic running between >>>>>>>>> it and the CN. >>>>>>>>> The other issue is related to cost for certain times of day. >>>>>>>>> This is a routing issue in the HA and has nothing to do with >>>>>>>>> which interface the MN selects. The selected CoA has zero >>>>>>>>> impact on the HA's upstream selection. Completely irrelevant actu= ally. >>>>>>>>> Of course, as far as cost on the visited link, the MN knows best. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> - Access provider may set up different parameters for traffic >>>>>>>>>> shaping for each of HA interfaces. These preferences may vary >>>>>>>>>> independently of change of backbone provider but dependently >>>>>>>>>> on the time of day. >>>>>>>>>> The rest you know, whether it changes somebodies opinion. >>>>>>>>>=20 >>>>>>>>> =3D> But again, this has zero effect on CoA selection. The two >>>>>>>>> issues are completely orthogonal. Selecting CoA1 or CoA2 has >>>>>>>>> zero impact on the HA's upstream route. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> - I presume that in RO mode this is similar to HA mode, and >>>>>>>>>> I'm in when it comes to send rules in reverse direction between = CN >>>>>>>>>> and MN. >>>>>>>>>> Benefits of doing that is that any change percieved by CN as >>>>>>>>>> important to react upon can be expressed in proposal of new rule= s. >>>>>>>>>> The sources causing changes may include but not limited to, >>>>>>>>>> are user, network managemnt events, application generated events= , >>>>>>>>>> etc. >>>>>>>>>>=20 >>>>>>>>>> So feel free to consider this as benefits or not >>>>>>>>>=20 >>>>>>>>> =3D> You seem to think that there is a relationship between >>>>>>>>> upstream routing and CoA selection. That's not the case at all. >>>>>>>>> These are two different addresses from two different networks. >>>>>>>>>=20 >>>>>>>>> Hesham >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> /yuri >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>>> Sent: Wednesday, June 03, 2009 11:47 AM >>>>>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>>> Cc: mext@ietf.org >>>>>>>>>> Subject: Re: [MEXT] Important considerations for >>>>>>>>>> directionality of flowbindings >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 3/06/09 7:33 PM, "Yuri Ismailov" >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hesham, >>>>>>>>>>>=20 >>>>>>>>>>> Whenever we talk about sending additional information, the >>>>>>>>>>> "waste of bandwidth" can be brought up. So I do not have an >>>>>>>>>>> answer for that besides speculations around it. >>>>>>>>>>=20 >>>>>>>>>> =3D> no no, I don't mean it literally, I mean that the message >>>>>>>>>> doesn't do anything, i.e. Has no benefit. >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Speaking about benefits, everybody who knows the area is >>>>>>>>>>> capable of turning things up side down. I assume it is >>>>>>>>>>> subjective standpoint of considering things as benefits or >>>>>>>>>>> disadvantages and all is about to agree or disagree. >>>>>>>>>>=20 >>>>>>>>>> =3D> That's fine, I'm asking for benefits in your opinion not >>>>>>>>>> someone else's. >>>>>>>>>> It's impossible to discuss this if I can't see any benefits >>>>>>>>>> because you didn't send any. What you sent were actions that >>>>>>>>>> can be done by the HA and I responded by saying that the same >>>>>>>>>> (or >>>>>>>>>> more) information is available to the MN. Therefore, if you >>>>>>>>>> think there are additional benefits to doing this in the HA >>>>>>>>>> then you need to tell us. >>>>>>>>>>=20 >>>>>>>>>> The bottom line is this: MIP works by letting the MN install >>>>>>>>>> bindings in the HA. If you want things to work in reverse you >>>>>>>>>> need to justify it. I can't see any justifications because >>>>>>>>>> you're not answering my questions on your scenarios. So, count >>>>>>>>>> me out on the reverse direction :). >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> For >>>>>>>>>>> me those I wrote about are benefits or potential benefits if >>>>>>>>>>> you want. >>>>>>>>>>=20 >>>>>>>>>> =3D> No you didn't. You wrote about things that can be done. >>>>>>>>>> Many things can be done by many entities, the question is why >>>>>>>>>> the HA and not the MN. >>>>>>>>>>=20 >>>>>>>>>>> One important thing in the discussion, although mentioned, >>>>>>>>>>> but forgotten later is that by making rules distribution one >>>>>>>>>>> way only, we do create limitation for benefits, or potential >>>>>>>>>>> benefits if this sounds better. >>>>>>>>>>=20 >>>>>>>>>> =3D> Well, we won't know what we're missing unless someone tells u= s. >>>>>>>>>> So far no one has mentioned the advantages of doing things in=20 >>>>>>>>>> the reverse direction. >>>>>>>>>> There is always something missing from a protocol (it's=20 >>>>>>>>>> engineering), the question us whether it's significant or=20 >>>>>>>>>> worth the trouble. >>>>>>>>>>=20 >>>>>>>>>> Hesham >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> /yuri >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>>>> Sent: Wednesday, June 03, 2009 10:10 AM >>>>>>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>>>> Cc: mext@ietf.org >>>>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>>>> directionality of flowbindings >>>>>>>>>>>=20 >>>>>>>>>>> Yuri, >>>>>>>>>>>=20 >>>>>>>>>>> I can't parse those events you refer to. I'l answer both emails= =20 >>>>>>>>>>> here. >>>>>>>>>>> First the events you refer to: >>>>>>>>>>>=20 >>>>>>>>>>>> - network condition towards CN(s) >>>>>>>>>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>>>>>>>>>=20 >>>>>>>>>>> =3D> What's the event? A change in those conditions? The MN=20 >>>>>>>>>>> knows the conditions of the e2e path as well as or better=20 >>>>>>>>>>> than the HA. >>>>>>>>>>> What is the benefit of having the HA send a hint and how=20 >>>>>>>>>>> reliable is that hint anyway? >>>>>>>>>>>=20 >>>>>>>>>>>> - Access provider (any access, not necessarily wireless)=20 >>>>>>>>>>>> who offeres HA services preferences change >>>>>>>>>>>=20 >>>>>>>>>>> =3D> Preferences change to what?? How does it know if such=20 >>>>>>>>>>> change works for the MN at all? This is way too vague to be=20 >>>>>>>>>>> able to discuss tradeoffs. >>>>>>>>>>>=20 >>>>>>>>>>>> - Change of the access provider traffic to another backbone=20 >>>>>>>>>>>> provider due to the time of the day. >>>>>>>>>>>> - Traffic condition on HA interface, which accepts traffic=20 >>>>>>>>>>>> from MN if MN sends on some particular local interface >>>>>>>>>>>=20 >>>>>>>>>>> =3D> These are path changes. The HA has _no idea_ how such a=20 >>>>>>>>>>> change affects each MN/CN combination and it's "hint" can=20 >>>>>>>>>>> cause more problems than it solves. BTW, if you're talking=20 >>>>>>>>>>> about hints then we're no longer talking about installing=20 >>>>>>>>>>> bindings in the MN. This is a different topic. MIP doesn't=20 >>>>>>>>>>> transfer hints, it pretty much sends "orders" >>>>>>>>>>> from one end to another. >>>>>>>>>>>=20 >>>>>>>>>>> Now to the actions required by the MN: >>>>>>>>>>>=20 >>>>>>>>>>>> - reject, >>>>>>>>>>>> - re-evaluate and reject >>>>>>>>>>>> - re-evaluate and accept >>>>>>>>>>>> - accept >>>>>>>>>>>=20 >>>>>>>>>>> =3D> First, by assuming that the MN can reject the "hint" as=20 >>>>>>>>>>> you call it you invalidate the whole argument for the HA to=20 >>>>>>>>>>> install rules. >>>>>>>>>>> Rejecting a hint or even evaluating it means that the MN knows = more. >>>>>>>>>>> Therefore, the HA's hint is a complete waste of bandwidth. >>>>>>>>>>>=20 >>>>>>>>>>> I'm still confused about the _benefits_ you see here. Or are=20 >>>>>>>>>>> you assuming that the MN can't know those hints without the=20 >>>>>>>>>>> HA's involvement? But if you're assuming that, then how can=20 >>>>>>>>>>> it reject the hints? This whole proposal makes no sense to me=20 >>>>>>>>>>> at all. Not to mention the complexity you implicitly assume=20 >>>>>>>>>>> in order to generate those, hopefully reliable, hints. >>>>>>>>>>>=20 >>>>>>>>>>> Hesham >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 3/06/09 5:23 PM, "Yuri Ismailov"=20 >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Hesham, >>>>>>>>>>>>=20 >>>>>>>>>>>> In my view these are events not scenarious. These events are=20 >>>>>>>>>>>> known by HA but not MN. If HA acts upon events, given that=20 >>>>>>>>>>>> it knows somewhat more about MN, not only IP addresses, it=20 >>>>>>>>>>>> (HA) can generate new rules and send them as hint to MN.=20 >>>>>>>>>>>> Back again, MN has four >>>>>>>>>>>> options: >>>>>>>>>>>>=20 >>>>>>>>>>>> The benefit will be obviously that the new rules (if >>>>>>>>>>>> accepted) may llead to a better overall communication=20 >>>>>>>>>>>> characteristics. >>>>>>>>>>>>=20 >>>>>>>>>>>> /yuri >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> =3D> I'm trying to understand what you mean above. These are=20 >>>>>>>>>>>> all scenarios, the question is: What is the benefit for the=20 >>>>>>>>>>>> HA to transfer rules? The HA will not know the path between=20 >>>>>>>>>>>> the MN and CN more than either node does. So I don't=20 >>>>>>>>>>>> understand what _benefits_ you see here. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Pretty much sure that there are more examples and I=20 >>>>>>>>>>>> encourage to think about those not from MN point of view=20 >>>>>>>>>>>> but rather from the HA service provider. >>>>>>>>>>>>=20 >>>>>>>>>>>> /yuri >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>>>>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>>>>> Cc: mext@ietf.org >>>>>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>>>>> directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Yuri, >>>>>>>>>>>>=20 >>>>>>>>>>>> It is just rules TRANSFER which is the matter of MIP. So=20 >>>>>>>>>>>> where is the logic when saying that MN to HA rules transfer=20 >>>>>>>>>>>> is a practical engineering and HA to MN is an academic=20 >>>>>>>>>>>> interest? >>>>>>>>>>>>=20 >>>>>>>>>>>> =3D> I think we've (I'm including myself) highlighted several=20 >>>>>>>>>>>> reasons for why it makes little sense to transfer rules=20 >>>>>>>>>>>> from HA to MN. >>>>>>>>>>>> Instead of rat-holing on theory Vs practice, you (or others=20 >>>>>>>>>>>> advocating the other direction) need to come up with=20 >>>>>>>>>>>> reasons for doing things this way. This way we can think=20 >>>>>>>>>>>> like engineers about tradeoffs. >>>>>>>>>>>> Absent that, I don't see any point in having theory Vs=20 >>>>>>>>>>>> practice high level discussions, which will lead nowhere. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards >>>>>>>>>>>> Yuri >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>>>>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>>>>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>>>>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>>>>> directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi Pierrick, >>>>>>>>>>>>=20 >>>>>>>>>>>> On Jun 2, 2009, at 4:11 PM,=20 >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>> Please see inline comment. >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>> Pierrick >>>>>>>>>>>>=20 >>>>>>>>>>>> ________________________________________ >>>>>>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>>> De la part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 09:3= 5 =C0 : >>>>>>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important=20 >>>>>>>>>>>> considerations for directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham, >>>>>>>>>>>> This is nice story and makes some sense for the discssion,=20 >>>>>>>>>>>> however some details are ommited. In your adventure with=20 >>>>>>>>>>>> the helpdesk, it (the >>>>>>>>>>>> helpdesk) is a third party service and thus your=20 >>>>>>>>>>>> conclusions make sence. >>>>>>>>>>>> Think of the situation when superior of a heldesk person=20 >>>>>>>>>>>> will tell him/her to check access point in some room. Would=20 >>>>>>>>>>>> it be the same reaction? I assume not. By that I mean that=20 >>>>>>>>>>>> if, for example, I'll install home agent in my home=20 >>>>>>>>>>>> network, I can make it know anything I want about MN, and=20 >>>>>>>>>>>> more intresting is that how I will do it, does not require=20 >>>>>>>>>>>> any standardization. >>>>>>>>>>>> In other words, I'm superior of my HA. >>>>>>>>>>>> This situation is not unthinkable, I personally believe=20 >>>>>>>>>>>> that this is much more efficient way of using HA=20 >>>>>>>>>>>> fnctionality as opposed to big service providers who will=20 >>>>>>>>>>>> have to fight with scalability and performance. >>>>>>>>>>>> However, one does not exclude another. >>>>>>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> The difference between policy and rules is not only a=20 >>>>>>>>>>>> matter of conversion. A policy, is a static, or=20 >>>>>>>>>>>> quasi-static, set of guidance for the MN (e.g use access=20 >>>>>>>>>>>> network X for application type >>>>>>>>>>>> A,...) while a rule update requires to be more dynamic. I mean= : >>>>>>>>>>>> eventually a policy could be updated depending on network=20 >>>>>>>>>>>> condition (e.g if X overloaded, use access network Y for=20 >>>>>>>>>>>> application type A,...) but a rule reacts on local triggers (e= .g. >>>>>>>>>>>> modification of the radio link >>>>>>>>>>>> quality) with a shorter period of variation. So, IMHO,=20 >>>>>>>>>>>> there is no requirement for updating policy on a short=20 >>>>>>>>>>>> period and out-of-band mechanism can be used (e.g. IEEE >>>>>>>>>>>> 802.21 in push mode,...). >>>>>>>>>>>>=20 >>>>>>>>>>>> Fully agree! >>>>>>>>>>>> This is why I do not support the exchange of rules from the=20 >>>>>>>>>>>> HA to the MN. >>>>>>>>>>>> Policies may be exchanged from the HA to the MN, but MIP is=20 >>>>>>>>>>>> definitely not the protocol to transport them. >>>>>>>>>>>>=20 >>>>>>>>>>>> Nicolas >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> My 2 cents... >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Is there any reason to restrict where such convertion takes pl= ace? >>>>>>>>>>>> True >>>>>>>>>>>> that a HA does not know what is going on in the access=20 >>>>>>>>>>>> network, on the other hand HA may know what is the network=20 >>>>>>>>>>>> condition between HA and correspondent node. Either of this=20 >>>>>>>>>>>> information is important, if not equally important. >>>>>>>>>>>> It is not really difficult to let an MN to reject rules=20 >>>>>>>>>>>> sent by HA, which in my view would be quite natural. This=20 >>>>>>>>>>>> implies that HA must follow the rules installed by MN until=20 >>>>>>>>>>>> explicit acceptance has been received from MN. >>>>>>>>>>>> Such procedure is very similar to an MN beahviour when=20 >>>>>>>>>>>> initiating new BU, where MN is not supposed to send any=20 >>>>>>>>>>>> traffic before BU confirmation. >>>>>>>>>>>> BTW, what is the numerical representation of "rough consensus"= ? >>>>>>>>>>>> I assume is when majority is for, is it so? >>>>>>>>>>>> Yuri >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>>> On Behalf Of Hesham Soliman >>>>>>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>>>>>> To: mext >>>>>>>>>>>> Subject: [MEXT] Important considerations for directionality=20 >>>>>>>>>>>> of flow bindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>> I've always been a fan of the IETF's tradition of rough=20 >>>>>>>>>>>> concensus (as opposed to voting). To me, this implies that=20 >>>>>>>>>>>> you need to get your point across and get other people to=20 >>>>>>>>>>>> see that point of view. >>>>>>>>>>>> As opposed to other organisations that require their=20 >>>>>>>>>>>> members to vote and end up with rigid political positions. >>>>>>>>>>>>=20 >>>>>>>>>>>> The chairs asked us about the directionality question of=20 >>>>>>>>>>>> the flows bindings. >>>>>>>>>>>> On the charter question, I said that the charter doesn't=20 >>>>>>>>>>>> need to mention how a solution should work, but rather what=20 >>>>>>>>>>>> problem needs to be solved. >>>>>>>>>>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>>>>>>>>>> transferring rules "between" the MN and HA without=20 >>>>>>>>>>>> mentioning directions. >>>>>>>>>>>>=20 >>>>>>>>>>>> Nevertheless, we still need to agree on identifying the=20 >>>>>>>>>>>> requirement for the solution. And when it comes to this,=20 >>>>>>>>>>>> I'm strongly against voting and I'll practice this by=20 >>>>>>>>>>>> explaining in this email why I think rules can not be=20 >>>>>>>>>>>> transferred from the HA to the MN and that the only=20 >>>>>>>>>>>> direction that makes sense in MIP is >>>>>>>>>>>> MN->HA. I'll deliberately ignore arguments like "some=20 >>>>>>>>>>>> MN->people want >>>>>>>>>>>> this" or "an SDO wants this". They fall under the=20 >>>>>>>>>>>> "meaningless words" >>>>>>>>>>>> category and I'm incapable of discussing them because they=20 >>>>>>>>>>>> come with voting attitudes. They all need to be justified=20 >>>>>>>>>>>> if the WG wants to have a technical _discussion_. >>>>>>>>>>>>=20 >>>>>>>>>>>> Here are my reasons: >>>>>>>>>>>>=20 >>>>>>>>>>>> 1. The HA does not know whether a CoA is tied to a certain=20 >>>>>>>>>>>> access technology. It is one thing for the HA to send a=20 >>>>>>>>>>>> message saying "forward port 80 traffic on a wifi link" (a >>>>>>>>>>>> policy) and a completely different thing to say "forward=20 >>>>>>>>>>>> port 80 traffic using CoA 3ffe::1" >>>>>>>>>>>> (a rule). >>>>>>>>>>>>=20 >>>>>>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem now? >>>>>>>>>>>> The problem is that the HA has no idea about dynamic=20 >>>>>>>>>>>> changes on that wifi link. It doesn't know if it's=20 >>>>>>>>>>>> congested, it doesn't know what application is using port=20 >>>>>>>>>>>> 80 (it doesn't have to be web >>>>>>>>>>>> traffic) or port 8000 for that matter and doesn't even know=20 >>>>>>>>>>>> if the AP of that wifi link works at all. >>>>>>>>>>>> Finally, it >>>>>>>>>>>> doesn't know the user's policies or other admin policies=20 >>>>>>>>>>>> for that MN. >>>>>>>>>>>> This type of information needs to be sent regularly because=20 >>>>>>>>>>>> it changes all the time and requires serious cross layer=20 >>>>>>>>>>>> integration including sometimes layer 8 integration! It's=20 >>>>>>>>>>>> completely impractical. >>>>>>>>>>>>=20 >>>>>>>>>>>> 3. If the HA installed rules in the MN, what happens if the=20 >>>>>>>>>>>> MN wants to change those rules. Say the wifi link went=20 >>>>>>>>>>>> down, or the MN's wifi interface went down and it wants to=20 >>>>>>>>>>>> move that traffic to another interface. Would the HA reject=20 >>>>>>>>>>>> such move? >>>>>>>>>>>> Does the MN have to justify to the HA why it needs to move=20 >>>>>>>>>>>> traffic? Does that involve writing a letter perhaps? >>>>>>>>>>>> If you say "well in that case, the HA should let the MN=20 >>>>>>>>>>>> move the traffic" >>>>>>>>>>>> then I'll ask you: what's the point of having the HA=20 >>>>>>>>>>>> install this stuff if it has no authority and how does it=20 >>>>>>>>>>>> know the reason for the MN's movement of the flow? >>>>>>>>>>>> The way to control how users do things is to incentivise=20 >>>>>>>>>>>> them with charging models and show them that things work=20 >>>>>>>>>>>> better on certain technologies, not by installing rules=20 >>>>>>>>>>>> that can't be followed. It's a broken mindset and we've=20 >>>>>>>>>>>> known that it's broken for a long time. >>>>>>>>>>>>=20 >>>>>>>>>>>> 4. Some people mentioned that the HA should be able to=20 >>>>>>>>>>>> revoke flows on the MN. I'm perfectly fine with that, just=20 >>>>>>>>>>>> extend the binding revocation draft to handle flows and the=20 >>>>>>>>>>>> rest is pretty straight forward. >>>>>>>>>>>>=20 >>>>>>>>>>>> Finally, I'll indulge in a true story that happened to me a=20 >>>>>>>>>>>> few years ago when I found that my wifi link wasn't working=20 >>>>>>>>>>>> in a hotel (no >>>>>>>>>>>> radio) >>>>>>>>>>>> and called the help desk. He insisted that the link was up=20 >>>>>>>>>>>> an I insisted that it wasn't. When I asked him to tell me=20 >>>>>>>>>>>> how he knows the link is up he said: I can ping the AP! Of=20 >>>>>>>>>>>> course after another >>>>>>>>>>>> 5 minutes of trying to convince him that pinging the AP=20 >>>>>>>>>>>> doesn't mean the radio is actually working he sent someone=20 >>>>>>>>>>>> to the hotel who in turn realised that the radio was not worki= ng. >>>>>>>>>>>> For those people who want rules to be transferred from the=20 >>>>>>>>>>>> HA to the MN, please think of your HA as this help desk=20 >>>>>>>>>>>> person, i.e. >>>>>>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>>>>>=20 >>>>>>>>>>>> I hope this helps with the realisation that decisions can't=20 >>>>>>>>>>>> be made here based on voting and that there is little merit=20 >>>>>>>>>>>> to transferring rules from the HA to the MN. Policies can=20 >>>>>>>>>>>> be transferred without any problems, but not rules. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From yuri.ismailov@ericsson.com Tue Jun 9 02:09:09 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4043A6961 for ; Tue, 9 Jun 2009 02:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.099 X-Spam-Level: X-Spam-Status: No, score=-8.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 r9dOj2KgFZDU for ; Tue, 9 Jun 2009 02:09:05 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 3CAD13A6898 for ; Tue, 9 Jun 2009 02:09:04 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9cae00000140d-1e-4a2e26b4ba13 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 42.9D.05133.4B62E2A4; Tue, 9 Jun 2009 11:09:08 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 11:09:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Jun 2009 11:09:07 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrA= References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 09 Jun 2009 09:09:07.0941 (UTC) FILETIME=[F1D65150:01C9E8E1] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 09:09:09 -0000 =20 -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Tuesday, June 09, 2009 10:33 AM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of = flowbindings >> First, is that we have agreed already that we are talking about = interfaces. >> Yes, we are talking about interfaces configured with CoA. Interfaces >> configured with HoA does not give any information about >> characteristices of interfaces configured with CoA, thus choosing HoA >> or HA can not provide any meaningful information about access >> characteristics. Thus it is not clear at all where from comes idea = about >> relevance to HA selection. >=20 > =3D> The hints that you were suggesting that the HA sends are only = relevant to > HoA selection. Do you agree? > No, I explained above why. HoA selection is meaningless in general = because > does not provide any usable information for selection of interfaces. =3D> Sigh..Yuri, we agree on that. But then you still think that HA = hints somehow magically give information to the MN about its interfaces so it knows better what to choose. HA knows which CoA (according to installed bindings) have got changes in = communication due to link downgrade. By receiving rules from HA, MN will know which interfaces are affected. Changes may take place either on a local access (within access provider = network) or towards backbone provider, or in the worst case both. I explained earlier that in either case MN does not know about that. In = the best case MN may know about local changes if and only if correspondent support is implemented in the MN. This can = be done either as application or operating system support. Both are questionable to expect. IP and any of its sublayers do not have this information. >=20 >> In all my examples (e.g. the latest one about broadband operators) it >> does not matter which HA (HoA) is used. All what matters is which >> access MN uses and if there was traffic shaping policy applied to = that access >> by an access provider. >> We have agreed that MN can not know about the later. HA can. >=20 > =3D> No! You were talking about traffic shaping by the HA or its = upstream ISP. > What do you mean by "provider" above? Where is the traffic being = impacted? > I'm not aware of any HA installed by any of access providers at the = moment > (any information about that would be highly appreciated). Traffic = shaping, on > the other hand, is applied in reality by some access providers, which = have a > quota on the amount of traffic sent within a period of time, typically = over a > month. > By provider I mean any provider who offers connectctivity to global = Internet. > A provider can offer such connectivity over single access technology = or > multiple different access technologies =3D> So where is the traffic shaping done in your scenario? Before you = said it was upstream from the HA, which led me to the answers I gave earlier. = Now where is it done in this discussion? FWIW, if it's done by the HA or upstream from the HA it's completely irrelevant to this discussion. That's what you've said. I repeateadly wrote about what I have written = above without any objection and/or attention. The traffic shaping is applied by an access provider. >=20 >>=20 >> Second, is that we are talking about sending rules from HA to MN. I >> call these rules hints, because and only because in my view MN should >> have rights to ignore the rules from HA. Both transportwise and >> contentwise, we are still talking about rules. At the moment I do not >> see any specific need for specific types of hints. >=20 > =3D> If we're talking about CoA selection I don't see any relevance to = those > hints. The only way you can show there is relevance is by providing an > example. The example you provided had no relevance to CoA selection. I = don't > understand why we need to go back two emails again. If you still think = your > scenario had relevance to CoA selection then please respond to my = earlier > response to your scenario. >=20 > Here I call you to read my emails as well. I explained that CoA = selection is > the result of interface selection. We are talking about selecting = interfaces > based on their characteristics for particular flows. Information about > downgrading the link performance is relevant to the communication > charachteristics of flows sent through that interface. =3D> Relevant to who??? It's relevant to the MN and is known by the MN. = How does the HA fit in here? It is relevant to MN for interface selction. Why it is not known by MN = see above >=20 >>=20 >> Information about the fact that up/down link from/to HA for a >> particular interface was downgraded is very relevant for MN because >> based on this information MN can select another interface for some of >> its flows and make correspondent move. > =3D> Are you saying the MN will notify the HA everytime I do this: > Ifdown eth1: ifup eth1 >=20 > Why on earth would you do that? > If you had flows running on eth1 before you have performed "ifdown = eth1" and > you want this flows to continue, you apperantly should move flows to = another > interface. If the current rule set in the MN changes, then the rule = set in the > HA has to be synchronized with what MN has generated due to "ifdown = eth1" > event. =3D> Yes we do that with the BU, I still don't see what the HA->MN does = here. Does this imply that rule sets may be out of sync between MN and HA? >=20 > If this is not the case then what is the objactive of >> interfaces selection? If better choice of interface for applications >> is not an objective then why bother about flow mobility at all? >=20 > =3D> I don't understand what you're saying Yuri. Please respond to my = earlier > email which responded to your scenario. I can't see how you still = think that > the HA can influence CoA selection. >=20 > The HA is sending the rules where particlar flow(s) are suggested to = move to > another interface. =3D> Well, as I said, at least a dozen times, there is zero information available to the HA to make this suggestion. So unless you provide = concrete information to transfer I really can't see any point in this proposal. You re saying, and I'm providing examples and scenarious. The point is = to have meaning in interface selection. /yuri Hesham >=20 > /yuri > Hesham >=20 >>=20 >> Regards >> Yuri >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Monday, June 08, 2009 4:29 PM >> To: Yuri Ismailov; Nicolas Montavont; >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of >> flowbindings >>=20 >>=20 >>=20 >>=20 >> On 9/06/09 12:12 AM, "Yuri Ismailov" = wrote: >>=20 >>> =20 >>> =3D> Yes but I still think you're talking about something else. The >>> interface you're talking about seems to be associated with the HoA. >>> This is the only case where I can see the relevance of HA hints (not >>> rules). The interfaces I'm talking about and discussed in the = context >>> of flow bindings are those associated with CoAs. There is nothing >>> coming from the HA about its links ...etc that can have any impact = on >>> CoA selection. >>>=20 >>> Hesham >>> here I tend to agree. I actually ment interfaces with CoA, but now >>> realized that in such configuration, where each of interfaces has >>> it's own HA configured, it is most likely that each of interfaces >>> will have different HoA. >>> Once this is the case then moving a flow between those interfaces >>> will lead to change of HoA. As we are in MIP context, I would better >>> avoid that. In the whole discussion I mean interafces with CoA >>> because selection of HoA and/or associated to it interface can not = be >>> based on physical characteristics of that interface. >>=20 >> =3D> Sounds fine to me. >>=20 >>>=20 >>> So the valid and meaningful scenario is moving flow(s) between >>> interfaces associated with the same HA, whether all interfaces of = the >>> MN or some of them will be configured this way does not really = matter. >>>=20 >>> Fine with me. Should we finalize then? As I see it, once there is a >>> meaningful information, which can be sent in HA -> MN direction, = then >>> MN can use it for re-evaluting policies and producing the new set of >>> rules. Definetely not at all times new rules will be produced, they >>> may stay unchanged, as it will be the case with many other events >>> taking place at either side: MN or HA. >>>=20 >>> Is that correct? >>=20 >> =3D> So now that we agree that we are only talking about CoAs then I >> don't see any meaningful information coming from the HA. Hints about >> upstream routing changes ...etc are relevant to HoA selection (even = if >> the HoA is not tied to a physical interface it doesn't matter). This >> is an interesting problem to discuss but I want to be clear on its = context. >> So to summarise my opinion: >> HA-> MN hints (not rules) may be relevant for intial HoA selection = for >> certain connections. The types of hints and how to formulate this in = a >> global manner can lead to interesting work (although it's a complex = problem). >> However, this information is not in anyway relevant to CoA/physical >> interface selection on the MN. >>=20 >> Hesham >>=20 >>=20 >>>=20 >>> Regards >>> Yuri >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Monday, June 08, 2009 2:00 PM >>> To: Yuri Ismailov; Nicolas Montavont; >>> pierrick.seite@orange-ftgroup.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Important considerations for directionality of >>> flowbindings >>>=20 >>> Yuri, >>>=20 >>> I think we're getting close here. >>>=20 >>>=20 >>> On 8/06/09 6:29 PM, "Yuri Ismailov" = wrote: >>>=20 >>>> Hesham, It looks like that the only point of disagreement is about >>>> changing HA and mapping between HA and access. >>>> Some explanations of what I mean below: >>>>=20 >>>>=20 >>>> 1. Changing HA. >>>> As it follows from group charter change of HA is in the plans of >>>> MEXT WG. I assume that this is going to be a separate work item >>>> because the reason specified for that is very specific and relates >>>> to deployment more than to flow mobility. Do not want to speculate, >>>> about this right now but the change of HA does not necessarily = means >>>> change of rules. >>>> So the proposal is to not to discuss change of HA as you suggested. >>>=20 >>> =3D> Agreed. >>>=20 >>>>=20 >>>> 2. In my example I do not mean change of HA as an explicit = procedure >>>> specified separately. One confirmation to that is that single HA = for >>>> all interfaces is included and valid option. Based on the HA -> MN >>>> exchange, the MN may perform interface selection procedure and may >>>> choose another interface for some flow(s). In multiple HA case it >>>> will result of the rules update MN -> HA to the HA which is = relevant >>>> for the new interface chosen for flows. Please notice, There is >>>> nothing about HA change, only about interface selection. >>>=20 >>> =3D> Yes but I still think you're talking about something else. The >>> interface you're talking about seems to be associated with the HoA. >>> This is the only case where I can see the relevance of HA hints (not >>> rules). The interfaces I'm talking about and discussed in the = context >>> of flow bindings are those associated with CoAs. There is nothing >>> coming from the HA about its links ...etc that can have any impact = on >>> CoA selection. >>>=20 >>>>=20 >>>> 3. I do not map HA and access. It is allowed for any access = provider >>>> to offer HA service and once this is the case it will be so. Thus = an >>>> MN can have multiple HA configured for the use on different = interfaces. >>>=20 >>> =3D> Good, we agree on that too. >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> Regards >>>> Yuri >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Friday, June 05, 2009 4:18 PM >>>> To: Yuri Ismailov; Nicolas Montavont; >>>> pierrick.seite@orange-ftgroup.com >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Important considerations for directionality of >>>> flowbindings >>>>=20 >>>>=20 >>>>=20 >>>>> First is that I assume that we have simulteneous multiaccess in >>>>> mind, i.e. MN has more than one interface to choose from for its >>>>> flows. If this is not the case then I will stop the discussion. >>>>> This assumption is based on the fact that we are (I hope at least) >>>>> discussing flow mobility. >>>>=20 >>>> =3D> Sure. >>>>=20 >>>>>=20 >>>>> Secondly, I consider that MN chooses an interface but not CoA. I >>>>> gave a though about that and did not come up with any information >>>>> which can be derived from CoA in order to choose it. An interface >>>>> has at least expected characteristics, thus can be a subject of >>>>> choice. Any clarification about that would be appreciated. >>>> =3D> An application would choose an interface, but of course the IP >>>> stack selects the corresponding address. I'm sure there is no >>>> disagreement there. >>>>=20 >>>>>=20 >>>>> Next assumptions are about possible configurations of HA >>>>> - Single HA for all interfaces configured in the mobile. HA can >>>>> belong to any of the access providers of each of access technology >>>>> used by MN. >>>>=20 >>>> =3D> Ok. >>>>=20 >>>>>=20 >>>>> - One HA per access or set of accesses, which is subset of all >>>>> access techologies presented or potentially may be presented >>>>> (detached >>>>> devices) in MN. >>>>=20 >>>> =3D> Now you're getting into a different problem space from flow = mobility. >>>> This is why I wanted you to break the scenario down. We are not >>>> dealing with multiple HoAs in this work item, we're dealing with >>>> multiple CoAs, i.e. One HoA. >>>>=20 >>>>> Anticipating numerous questions about that can say that I looked = at >>>>> such configuration and did not find anything strange with it, i.e. >>>>> (1) it works, >>>>> (2) it does not require any change to MIP or any other of its >>>>> extensions. (3) Configuration is performed per interface and does >>>>> not introduce any ambiguities. (4) it is natural for access >>>>> provider to offer HA service. >>>>=20 >>>> =3D> Yes of course it works but as I read this I'm guessing that = you >>>> want the MN to change HoA. This is not the problem we're discussing >>>> in this WG. >>>> Another issue, I'm not comfortable with the wording of "HA per = access" >>>> because they're not tied to access. Let's just say there are >>>> multiple Has and not associate it with an access. >>>>=20 >>>>>=20 >>>>> - "Residential" HA. Assumption is that it can be either one of = HA's >>>>> or a single HA for all types of accesses. This is the matter of MN >>>>> configuration. >>>>> "Residential". >>>>=20 >>>> =3D> Please don't tie HA to access. >>>>=20 >>>>>=20 >>>>> - Any HA may have multiple interfaces, e.g. "residential" HA may = be >>>>> connected to mobile broadband, DSL, etc. >>>>=20 >>>> =3D> sure >>>>=20 >>>>>=20 >>>>> Next assumption comes from the example (e.g. latest one) >>>>> - Traffic shaping is applied in both directions (up/down) link (in >>>>> practice this is the case). >>>>> - Traffic shaping (TS) is applied to user subscription. In other >>>>> words TS is applied to packets belonging to a particular >>>>> subscription but not to an aggregated traffic on gateway = interfaces. >>>>> HA is not necessary (however, nothing prevents from that) a = gateway >>>>> where TS is applied. >>>>>=20 >>>>>=20 >>>>> I hope that I have not missed something, although it may be = possible. >>>>> If we can agree on that or correct if something is wrong here and >>>>> agree later then we know how to proceed further on >>>>=20 >>>> =3D> Your scenario is fine (with the wording changes for tying Has = to >>>> access). >>>> But I want to pre-empt any suggestion that the HA will tell the MN >>>> to use a different HoA. This is very possible but it's not the >>>> problem being discussed here. It may well be something for charter >>>> discussion but it has zero impact on flow bindings for multiple = CoAs. >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> /yuri >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: Friday, June 05, 2009 11:37 AM >>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>> pierrick.seite@orange-ftgroup.com >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Important considerations for directionality of >>>>> flowbindings >>>>>=20 >>>>> Yuri, >>>>>=20 >>>>>=20 >>>>>> Still not clear for me why you call scenarious invalid? >>>>>> Some broadband providers (this is used in practice) have quota on >>>>>> the amount of traffic sent by users. Once quota is exceeded >>>>>> provider downgardes outgoing traffic from its network to 64Kbs >>>>>> (this figure is the real example from real provider). Such >>>>>> combination of to paths, where one is high speed, lets say 10 Mbs >>>>>> and another one is 64Kbs is quite crusual to apps running on top = of TCP. >>>>>> Not for all types of traffic though. >>>>>=20 >>>>> =3D> Yes I know the scenario but I keep saying to you that the = change >>>>> in upstream routing in the HA has nothing to do with CoA selection >>>>> by the MN in the visited network. If anything, you want the MN to >>>>> change it's HoA depending on how the switch to another upstream = ISP works. >>>>> It's a completely irrelevant issue to this discussion. Do you = agree? >>>>> If not why not? I really want to see an answer to this point. >>>>>=20 >>>>> =20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> MN can not know about this situation. Nobody will send this >>>>>> information to MN. >>>>>=20 >>>>> =3D> Yes and if it knows what will it do??? If you can answer that >>>>> you will fix the deadlock we have. >>>>>=20 >>>>>> That means that MN will choose its interfaces based on its >>>>>> knowledge about 10Mbs link capabilities. >>>>>=20 >>>>> =3D> You're talking about two different things. The MN doesn't = choose >>>>> the HA's outgoing interface! What am I missing? >>>>>=20 >>>>> Obtaining this isnformation from HA is quite >>>>>> significant to make a better decision about choice of interfaces >>>>>> for its flows. >>>>>> This is concrete example of what happens in the reality. >>>>>> Do you consider that this information will be useless for MN? >>>>>=20 >>>>> =3D> Completely useless. Unless I'm missing something in your = scenario. >>>>> Just write down step by step what will happen and include = messages. >>>>> I don't see how this can possibly be relevant to the MN. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>> Hesham >>>>>=20 >>>>>>=20 >>>>>> /yuri >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>> Sent: Thursday, June 04, 2009 4:38 PM >>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>> pierrick.seite@orange-ftgroup.com >>>>>> Cc: mext@ietf.org >>>>>> Subject: Re: [MEXT] Important considerations for directionality = of >>>>>> flowbindings >>>>>>=20 >>>>>> Yuri, >>>>>>=20 >>>>>>=20 >>>>>> On 5/06/09 12:01 AM, "Yuri Ismailov" = wrote: >>>>>>=20 >>>>>>> Hesham, >>>>>>>=20 >>>>>>> I provided several scenarious which you said are invalid. This = is >>>>>>> where my conclusion about standpoint comes from. >>>>>>> Whether you call hints policies or rules it does not change what >>>>>>> information can be provided by HA to MN. >>>>>>=20 >>>>>> =3D> It changes the outcome for the work item we're discussing. = I'm >>>>>> trying to come to a conclusion on this and there is a huge >>>>>> difference between transferring policies and installing flow = bindings. >>>>>>=20 >>>>>>> By sending rules HA does not install anything in MN. Likewise, = MN >>>>>>> does not install rules in HA, it informs HA about currently made >>>>>>> choices. >>>>>>> As I remember rules will not be valid until proper Ack arrival, >>>>>>> which for me means that may not be instantiated at all. >>>>>>> Niether rules nor polices are specific to MIP. As I wrote those >>>>>>> can be exchanged between hosts without any MIP implementation, >>>>>>> just for access selection purposes. Once it was decided to make >>>>>>> it as part of MIP protocol, I'm fine with that. Do not have any >>>>>>> idea to discuss this, while personally consider that the work on >>>>>>> rules transfer can very well fit into the MEXT group but as a >>>>>>> separate work item, but this is not the case now, so good enough = the way >>>>>>> it is. >>>>>>> And back again, it really gets repeated, so will lead to = nowhere, >>>>>>> you've got my arguments and tell that the information, which I'm >>>>>>> talking about, is not usefull. What can I say more? I can put = you >>>>>>> on my position and start asking questions instead of answering. >>>>>>> So, why it is not usefull? >>>>>>=20 >>>>>> =3D> I explained why the specific information you mentioned was = not >>>>>> useful/useable by the MN and this is what I referred to as = unanswered. >>>>>> Because if you agree with my previous explanations then we don't >>>>>> need to discuss it further. If you disagree you certainly didn't >>>>>> tell me why. You have the charge of proof because you want to >>>>>> change the way MIP works currently, that's all I'm trying to say. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>>=20 >>>>>>> /yuri >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>> Sent: Thursday, June 04, 2009 4:00 AM >>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>> Cc: mext@ietf.org >>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>> of flowbindings >>>>>>>=20 >>>>>>> Yuri, >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> Missing is additional information which may be helpful in = making >>>>>>>> better decision about interface selection by MN. >>>>>>>> Which information is that I wrote in my previous emails. Back = to >>>>>>>> my examples (not all, do not want to repeat myself). If HA will >>>>>>>> have changed traffic shaping parameters on one of the incoming >>>>>>>> or outgoing interfaces, this will be important information for = MN to >>>>>>>> know. >>>>>>>> We have agreed already that whether this information important >>>>>>>> or not, benfitial or not is a matter of standpoint. >>>>>>>=20 >>>>>>> =3D> I don't agree or like to think that it's a matter of = standpoint. >>>>>>> That's why I asked you on every point you raised and compared >>>>>>> this to the MN's knowledge on e2e basis. Once we have = "standpoints" >>>>>>> then we're getting outside the technical realm. The reason I >>>>>>> don't think it's useful is that this information cannot be used >>>>>>> by the MN to select a CoA. I've already stated that before and >>>>>>> you seemed to agree so I don't know why you repeat this as a >>>>>>> reason for the HA to install filters in the MN. Let me say it >>>>>>> again: There is no correlation between the routing on the HA's >>>>>>> upstream interfaces/ISP with the MN's selection of a CoA. >>>>>>>=20 >>>>>>>> I consider that knowing more is a benefit and will help to get >>>>>>>> better result. >>>>>>>>=20 >>>>>>>> My point is still the same. I see the reverse rules sending as >>>>>>>> possibility to provide more information to the MN, thus make MN >>>>>>>> to get to better decision about interface selection for its = flows. >>>>>>>> This point has not changed since the beginning of the = discussion. >>>>>>>=20 >>>>>>> =3D> This is why we're not making progress IMO: >>>>>>>=20 >>>>>>> 1. The hints you refer to are not the same things as installing >>>>>>> rules on the MN. Completely different information in fact. = You've >>>>>>> essentially proved that when you suggested that the MN can = accept >>>>>>> or reject them. So, let's not call them rules. The more direct >>>>>>> word for what you want to send is policies >>>>>>>=20 >>>>>>> 2. You didn't provide a valid scenario that we can discuss as to >>>>>>> why it's needed or how it could work. I've asked numerous >>>>>>> questions in each email that were not answered (with the >>>>>>> exception of the last email). It's not possible to progress the >>>>>>> discussion without answering each others' >>>>>>> questions. You can go back through the threads and verify this. >>>>>>>=20 >>>>>>> 3. If we're sending rules from the HA to the MN and the MN can >>>>>>> reject those rules then the whole exercise is pointless. You >>>>>>> really want to send policies not rules. I can imagine those >>>>>>> policies being one of the inputs that the MN uses to make a >>>>>>> decision. I still fail to see how anything happening on the HA's >>>>>>> upstream interfaces/ISP link can possibly influence the MN's >>>>>>> decision for CoA selection. >>>>>>> This is another unanswered question. >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>>=20 >>>>>>>> /yuri >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>> Sent: Wednesday, June 03, 2009 4:09 PM >>>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>> Cc: mext@ietf.org >>>>>>>> Subject: Re: [MEXT] Important considerations for directionality >>>>>>>> of flowbindings >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 3/06/09 10:47 PM, "Yuri Ismailov" = >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> Ok, see your point, however:-) >>>>>>>>>=20 >>>>>>>>> The major difference here is that your are talking about CoA >>>>>>>>> selection and I'm talking about interface selection. Quite a >>>>>>>>> big difference. >>>>>>>>=20 >>>>>>>> =3D> No, that's not the point really. The point is that there = is >>>>>>>> no relationship between CoA/interface selection on the MN and >>>>>>>> the upstream ISP for the home network. >>>>>>>>=20 >>>>>>>>> I do not see any grounds for MN to select CoA, based on what? >>>>>>>>> Prefix length? >>>>>>>>> While selection of an interface is based on expected >>>>>>>>> characteristics of the communication. Routes (up/down)link in >>>>>>>>> my opinion do have impact on the characteristics and this is >>>>>>>>> exactly the information missing in the MN when selecting = interface. >>>>>>>>=20 >>>>>>>> =3D> There is nothing missing for the MN to make this = selection. >>>>>>>> Please tell us specifically what is missing. You're changing >>>>>>>> points on me all the time now. >>>>>>>> Lets stick to one point at a time. What's missing? >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Whenever, MN decides to move a flow, the reason can be = anything >>>>>>>>> but not which CoA it has configured on each interface. >>>>>>>>>=20 >>>>>>>>> Another thing is that MN will notice something e2e if and only >>>>>>>>> if such support is implemented in the MN. >>>>>>>>=20 >>>>>>>> =3D> Of course, so what? >>>>>>>>=20 >>>>>>>> Moreover, this notice can not be made at IP layer. >>>>>>>>> TCP fights alone with all problems and never tells to any = other >>>>>>>>> layer what is going on. So what is left? Two options. Add this >>>>>>>>> support to operating system, which makes its (support) >>>>>>>>> existence questionable, or to applications, which is even more >>>>>>>>> questionable. >>>>>>>>=20 >>>>>>>> =3D> It's interesting that you think it's questionable to add = the >>>>>>>> support to the MN's OS but not questionable to add the support >>>>>>>> to the HA's OS, which will not lead to the same reliability as >>>>>>>> if it were done in the MN. It doesn't make sense to me. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Well, that's debatable, but this is clearly not a reason to >>>>>>>>>>> do anything. >>>>>>>>>>>=20 >>>>>>>>> Are you serious about that MIP may be broken because of that? >>>>>>>>=20 >>>>>>>> =3D> Yes! It's not designed to do what you want to do. Luckily, = in >>>>>>>> this case what you want, IMO, is broken anyway so it's not a = problem. >>>>>>>>=20 >>>>>>>> Hesham >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> /yuri >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>> Sent: Wednesday, June 03, 2009 1:15 PM >>>>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>> Cc: mext@ietf.org >>>>>>>>> Subject: Re: [MEXT] Important considerations for = directionality >>>>>>>>> of flowbindings >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Still some answers, despite knowing that in your opinion they >>>>>>>>>> are not benefits. >>>>>>>>>>=20 >>>>>>>>>> First of all MIP will not be breaked if the rules will be = sent >>>>>>>>>> in both directions. >>>>>>>>>=20 >>>>>>>>> =3D> Well, that's debatable, but this is clearly not a reason = to >>>>>>>>> do anything. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> - Access provider preferences relate to the use of backbone >>>>>>>>>> provider, which may vary with the time of day. Changing >>>>>>>>>> backbone provider can make quite big difference for >>>>>>>>>> commnication between HA (if HA service is provided by the = same >>>>>>>>>> access >>>>>>>>>> provider) and CN(s). >>>>>>>>>> The difference can be expressed in, let's say, number of = hops, >>>>>>>>>> load, possibly something else. Such change is an event and = may >>>>>>>>>> have an impact on the overall communication. This can be told >>>>>>>>>> directly to MN or HA. Direct communication to MN (if accepted >>>>>>>>>> as >>>>>>>>>> benefit:-)) in such case will need standardization. >>>>>>>>>> Communication of this information to HA does not (I consider >>>>>>>>>> this as a benefit). >>>>>>>>>> HA may act upon that event, and the rest you >>>>>>>>>> know: rules in reverse direction. >>>>>>>>>=20 >>>>>>>>> =3D> There is no need to _tell_ the MN anything. There are two >>>>>>>>> issues here. >>>>>>>>> First, changing network conditions are best known e2e. So the >>>>>>>>> MN will know that anyway based on the traffic running between >>>>>>>>> it and the CN. >>>>>>>>> The other issue is related to cost for certain times of day. >>>>>>>>> This is a routing issue in the HA and has nothing to do with >>>>>>>>> which interface the MN selects. The selected CoA has zero >>>>>>>>> impact on the HA's upstream selection. Completely irrelevant = actually. >>>>>>>>> Of course, as far as cost on the visited link, the MN knows = best. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> - Access provider may set up different parameters for traffic >>>>>>>>>> shaping for each of HA interfaces. These preferences may vary >>>>>>>>>> independently of change of backbone provider but dependently >>>>>>>>>> on the time of day. >>>>>>>>>> The rest you know, whether it changes somebodies opinion. >>>>>>>>>=20 >>>>>>>>> =3D> But again, this has zero effect on CoA selection. The two >>>>>>>>> issues are completely orthogonal. Selecting CoA1 or CoA2 has >>>>>>>>> zero impact on the HA's upstream route. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> - I presume that in RO mode this is similar to HA mode, and >>>>>>>>>> I'm in when it comes to send rules in reverse direction = between CN >>>>>>>>>> and MN. >>>>>>>>>> Benefits of doing that is that any change percieved by CN as >>>>>>>>>> important to react upon can be expressed in proposal of new = rules. >>>>>>>>>> The sources causing changes may include but not limited to, >>>>>>>>>> are user, network managemnt events, application generated = events, >>>>>>>>>> etc. >>>>>>>>>>=20 >>>>>>>>>> So feel free to consider this as benefits or not >>>>>>>>>=20 >>>>>>>>> =3D> You seem to think that there is a relationship between >>>>>>>>> upstream routing and CoA selection. That's not the case at = all. >>>>>>>>> These are two different addresses from two different networks. >>>>>>>>>=20 >>>>>>>>> Hesham >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> /yuri >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>>> Sent: Wednesday, June 03, 2009 11:47 AM >>>>>>>>>> To: Yuri Ismailov; Nicolas Montavont; >>>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>>> Cc: mext@ietf.org >>>>>>>>>> Subject: Re: [MEXT] Important considerations for >>>>>>>>>> directionality of flowbindings >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 3/06/09 7:33 PM, "Yuri Ismailov" >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hesham, >>>>>>>>>>>=20 >>>>>>>>>>> Whenever we talk about sending additional information, the >>>>>>>>>>> "waste of bandwidth" can be brought up. So I do not have an >>>>>>>>>>> answer for that besides speculations around it. >>>>>>>>>>=20 >>>>>>>>>> =3D> no no, I don't mean it literally, I mean that the = message >>>>>>>>>> doesn't do anything, i.e. Has no benefit. >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Speaking about benefits, everybody who knows the area is >>>>>>>>>>> capable of turning things up side down. I assume it is >>>>>>>>>>> subjective standpoint of considering things as benefits or >>>>>>>>>>> disadvantages and all is about to agree or disagree. >>>>>>>>>>=20 >>>>>>>>>> =3D> That's fine, I'm asking for benefits in your opinion not >>>>>>>>>> someone else's. >>>>>>>>>> It's impossible to discuss this if I can't see any benefits >>>>>>>>>> because you didn't send any. What you sent were actions that >>>>>>>>>> can be done by the HA and I responded by saying that the same >>>>>>>>>> (or >>>>>>>>>> more) information is available to the MN. Therefore, if you >>>>>>>>>> think there are additional benefits to doing this in the HA >>>>>>>>>> then you need to tell us. >>>>>>>>>>=20 >>>>>>>>>> The bottom line is this: MIP works by letting the MN install >>>>>>>>>> bindings in the HA. If you want things to work in reverse you >>>>>>>>>> need to justify it. I can't see any justifications because >>>>>>>>>> you're not answering my questions on your scenarios. So, = count >>>>>>>>>> me out on the reverse direction :). >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> For >>>>>>>>>>> me those I wrote about are benefits or potential benefits if >>>>>>>>>>> you want. >>>>>>>>>>=20 >>>>>>>>>> =3D> No you didn't. You wrote about things that can be done. >>>>>>>>>> Many things can be done by many entities, the question is why >>>>>>>>>> the HA and not the MN. >>>>>>>>>>=20 >>>>>>>>>>> One important thing in the discussion, although mentioned, >>>>>>>>>>> but forgotten later is that by making rules distribution one >>>>>>>>>>> way only, we do create limitation for benefits, or potential >>>>>>>>>>> benefits if this sounds better. >>>>>>>>>>=20 >>>>>>>>>> =3D> Well, we won't know what we're missing unless someone = tells us. >>>>>>>>>> So far no one has mentioned the advantages of doing things in = >>>>>>>>>> the reverse direction. >>>>>>>>>> There is always something missing from a protocol (it's=20 >>>>>>>>>> engineering), the question us whether it's significant or=20 >>>>>>>>>> worth the trouble. >>>>>>>>>>=20 >>>>>>>>>> Hesham >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> /yuri >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>>>> Sent: Wednesday, June 03, 2009 10:10 AM >>>>>>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>>>> Cc: mext@ietf.org >>>>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>>>> directionality of flowbindings >>>>>>>>>>>=20 >>>>>>>>>>> Yuri, >>>>>>>>>>>=20 >>>>>>>>>>> I can't parse those events you refer to. I'l answer both = emails=20 >>>>>>>>>>> here. >>>>>>>>>>> First the events you refer to: >>>>>>>>>>>=20 >>>>>>>>>>>> - network condition towards CN(s) >>>>>>>>>>>> - the sum of number of hops between MN -> HA and HA -> CN >>>>>>>>>>>=20 >>>>>>>>>>> =3D> What's the event? A change in those conditions? The MN=20 >>>>>>>>>>> knows the conditions of the e2e path as well as or better=20 >>>>>>>>>>> than the HA. >>>>>>>>>>> What is the benefit of having the HA send a hint and how=20 >>>>>>>>>>> reliable is that hint anyway? >>>>>>>>>>>=20 >>>>>>>>>>>> - Access provider (any access, not necessarily wireless)=20 >>>>>>>>>>>> who offeres HA services preferences change >>>>>>>>>>>=20 >>>>>>>>>>> =3D> Preferences change to what?? How does it know if such=20 >>>>>>>>>>> change works for the MN at all? This is way too vague to be=20 >>>>>>>>>>> able to discuss tradeoffs. >>>>>>>>>>>=20 >>>>>>>>>>>> - Change of the access provider traffic to another backbone = >>>>>>>>>>>> provider due to the time of the day. >>>>>>>>>>>> - Traffic condition on HA interface, which accepts traffic=20 >>>>>>>>>>>> from MN if MN sends on some particular local interface >>>>>>>>>>>=20 >>>>>>>>>>> =3D> These are path changes. The HA has _no idea_ how such a = >>>>>>>>>>> change affects each MN/CN combination and it's "hint" can=20 >>>>>>>>>>> cause more problems than it solves. BTW, if you're talking=20 >>>>>>>>>>> about hints then we're no longer talking about installing=20 >>>>>>>>>>> bindings in the MN. This is a different topic. MIP doesn't=20 >>>>>>>>>>> transfer hints, it pretty much sends "orders" >>>>>>>>>>> from one end to another. >>>>>>>>>>>=20 >>>>>>>>>>> Now to the actions required by the MN: >>>>>>>>>>>=20 >>>>>>>>>>>> - reject, >>>>>>>>>>>> - re-evaluate and reject >>>>>>>>>>>> - re-evaluate and accept >>>>>>>>>>>> - accept >>>>>>>>>>>=20 >>>>>>>>>>> =3D> First, by assuming that the MN can reject the "hint" as = >>>>>>>>>>> you call it you invalidate the whole argument for the HA to=20 >>>>>>>>>>> install rules. >>>>>>>>>>> Rejecting a hint or even evaluating it means that the MN = knows more. >>>>>>>>>>> Therefore, the HA's hint is a complete waste of bandwidth. >>>>>>>>>>>=20 >>>>>>>>>>> I'm still confused about the _benefits_ you see here. Or are = >>>>>>>>>>> you assuming that the MN can't know those hints without the=20 >>>>>>>>>>> HA's involvement? But if you're assuming that, then how can=20 >>>>>>>>>>> it reject the hints? This whole proposal makes no sense to = me=20 >>>>>>>>>>> at all. Not to mention the complexity you implicitly assume=20 >>>>>>>>>>> in order to generate those, hopefully reliable, hints. >>>>>>>>>>>=20 >>>>>>>>>>> Hesham >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 3/06/09 5:23 PM, "Yuri Ismailov"=20 >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Hesham, >>>>>>>>>>>>=20 >>>>>>>>>>>> In my view these are events not scenarious. These events = are=20 >>>>>>>>>>>> known by HA but not MN. If HA acts upon events, given that=20 >>>>>>>>>>>> it knows somewhat more about MN, not only IP addresses, it=20 >>>>>>>>>>>> (HA) can generate new rules and send them as hint to MN.=20 >>>>>>>>>>>> Back again, MN has four >>>>>>>>>>>> options: >>>>>>>>>>>>=20 >>>>>>>>>>>> The benefit will be obviously that the new rules (if >>>>>>>>>>>> accepted) may llead to a better overall communication=20 >>>>>>>>>>>> characteristics. >>>>>>>>>>>>=20 >>>>>>>>>>>> /yuri >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> =3D> I'm trying to understand what you mean above. These = are=20 >>>>>>>>>>>> all scenarios, the question is: What is the benefit for the = >>>>>>>>>>>> HA to transfer rules? The HA will not know the path between = >>>>>>>>>>>> the MN and CN more than either node does. So I don't=20 >>>>>>>>>>>> understand what _benefits_ you see here. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Pretty much sure that there are more examples and I=20 >>>>>>>>>>>> encourage to think about those not from MN point of view=20 >>>>>>>>>>>> but rather from the HA service provider. >>>>>>>>>>>>=20 >>>>>>>>>>>> /yuri >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>>>>>>>> Sent: Wednesday, June 03, 2009 8:41 AM >>>>>>>>>>>> To: Yuri Ismailov; Nicolas Montavont;=20 >>>>>>>>>>>> pierrick.seite@orange-ftgroup.com >>>>>>>>>>>> Cc: mext@ietf.org >>>>>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>>>>> directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Yuri, >>>>>>>>>>>>=20 >>>>>>>>>>>> It is just rules TRANSFER which is the matter of MIP. So=20 >>>>>>>>>>>> where is the logic when saying that MN to HA rules transfer = >>>>>>>>>>>> is a practical engineering and HA to MN is an academic=20 >>>>>>>>>>>> interest? >>>>>>>>>>>>=20 >>>>>>>>>>>> =3D> I think we've (I'm including myself) highlighted = several=20 >>>>>>>>>>>> reasons for why it makes little sense to transfer rules=20 >>>>>>>>>>>> from HA to MN. >>>>>>>>>>>> Instead of rat-holing on theory Vs practice, you (or others = >>>>>>>>>>>> advocating the other direction) need to come up with=20 >>>>>>>>>>>> reasons for doing things this way. This way we can think=20 >>>>>>>>>>>> like engineers about tradeoffs. >>>>>>>>>>>> Absent that, I don't see any point in having theory Vs=20 >>>>>>>>>>>> practice high level discussions, which will lead nowhere. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards >>>>>>>>>>>> Yuri >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Nicolas Montavont [mailto:ietf@montavont.net] >>>>>>>>>>>> Sent: Tuesday, June 02, 2009 5:47 PM >>>>>>>>>>>> To: pierrick.seite@orange-ftgroup.com >>>>>>>>>>>> Cc: Yuri Ismailov; hesham@elevatemobile.com; mext@ietf.org >>>>>>>>>>>> Subject: Re: [MEXT] Important considerations for=20 >>>>>>>>>>>> directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi Pierrick, >>>>>>>>>>>>=20 >>>>>>>>>>>> On Jun 2, 2009, at 4:11 PM,=20 >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>> Please see inline comment. >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>> Pierrick >>>>>>>>>>>>=20 >>>>>>>>>>>> ________________________________________ >>>>>>>>>>>> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>>> De la part de Yuri Ismailov Envoy=E9 : vendredi 29 mai 2009 = 09:35 =C0 : >>>>>>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important=20 >>>>>>>>>>>> considerations for directionality of flowbindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham, >>>>>>>>>>>> This is nice story and makes some sense for the discssion,=20 >>>>>>>>>>>> however some details are ommited. In your adventure with=20 >>>>>>>>>>>> the helpdesk, it (the >>>>>>>>>>>> helpdesk) is a third party service and thus your=20 >>>>>>>>>>>> conclusions make sence. >>>>>>>>>>>> Think of the situation when superior of a heldesk person=20 >>>>>>>>>>>> will tell him/her to check access point in some room. Would = >>>>>>>>>>>> it be the same reaction? I assume not. By that I mean that=20 >>>>>>>>>>>> if, for example, I'll install home agent in my home=20 >>>>>>>>>>>> network, I can make it know anything I want about MN, and=20 >>>>>>>>>>>> more intresting is that how I will do it, does not require=20 >>>>>>>>>>>> any standardization. >>>>>>>>>>>> In other words, I'm superior of my HA. >>>>>>>>>>>> This situation is not unthinkable, I personally believe=20 >>>>>>>>>>>> that this is much more efficient way of using HA=20 >>>>>>>>>>>> fnctionality as opposed to big service providers who will=20 >>>>>>>>>>>> have to fight with scalability and performance. >>>>>>>>>>>> However, one does not exclude another. >>>>>>>>>>>> Difference between policies and rules is a convertion step. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> The difference between policy and rules is not only a=20 >>>>>>>>>>>> matter of conversion. A policy, is a static, or=20 >>>>>>>>>>>> quasi-static, set of guidance for the MN (e.g use access=20 >>>>>>>>>>>> network X for application type >>>>>>>>>>>> A,...) while a rule update requires to be more dynamic. I = mean: >>>>>>>>>>>> eventually a policy could be updated depending on network=20 >>>>>>>>>>>> condition (e.g if X overloaded, use access network Y for=20 >>>>>>>>>>>> application type A,...) but a rule reacts on local triggers = (e.g. >>>>>>>>>>>> modification of the radio link >>>>>>>>>>>> quality) with a shorter period of variation. So, IMHO,=20 >>>>>>>>>>>> there is no requirement for updating policy on a short=20 >>>>>>>>>>>> period and out-of-band mechanism can be used (e.g. IEEE >>>>>>>>>>>> 802.21 in push mode,...). >>>>>>>>>>>>=20 >>>>>>>>>>>> Fully agree! >>>>>>>>>>>> This is why I do not support the exchange of rules from the = >>>>>>>>>>>> HA to the MN. >>>>>>>>>>>> Policies may be exchanged from the HA to the MN, but MIP is = >>>>>>>>>>>> definitely not the protocol to transport them. >>>>>>>>>>>>=20 >>>>>>>>>>>> Nicolas >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> My 2 cents... >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Is there any reason to restrict where such convertion takes = place? >>>>>>>>>>>> True >>>>>>>>>>>> that a HA does not know what is going on in the access=20 >>>>>>>>>>>> network, on the other hand HA may know what is the network=20 >>>>>>>>>>>> condition between HA and correspondent node. Either of this = >>>>>>>>>>>> information is important, if not equally important. >>>>>>>>>>>> It is not really difficult to let an MN to reject rules=20 >>>>>>>>>>>> sent by HA, which in my view would be quite natural. This=20 >>>>>>>>>>>> implies that HA must follow the rules installed by MN until = >>>>>>>>>>>> explicit acceptance has been received from MN. >>>>>>>>>>>> Such procedure is very similar to an MN beahviour when=20 >>>>>>>>>>>> initiating new BU, where MN is not supposed to send any=20 >>>>>>>>>>>> traffic before BU confirmation. >>>>>>>>>>>> BTW, what is the numerical representation of "rough = consensus"? >>>>>>>>>>>> I assume is when majority is for, is it so? >>>>>>>>>>>> Yuri >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 >>>>>>>>>>>> On Behalf Of Hesham Soliman >>>>>>>>>>>> Sent: Thursday, May 28, 2009 12:07 PM >>>>>>>>>>>> To: mext >>>>>>>>>>>> Subject: [MEXT] Important considerations for directionality = >>>>>>>>>>>> of flow bindings >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>> I've always been a fan of the IETF's tradition of rough=20 >>>>>>>>>>>> concensus (as opposed to voting). To me, this implies that=20 >>>>>>>>>>>> you need to get your point across and get other people to=20 >>>>>>>>>>>> see that point of view. >>>>>>>>>>>> As opposed to other organisations that require their=20 >>>>>>>>>>>> members to vote and end up with rigid political positions. >>>>>>>>>>>>=20 >>>>>>>>>>>> The chairs asked us about the directionality question of=20 >>>>>>>>>>>> the flows bindings. >>>>>>>>>>>> On the charter question, I said that the charter doesn't=20 >>>>>>>>>>>> need to mention how a solution should work, but rather what = >>>>>>>>>>>> problem needs to be solved. >>>>>>>>>>>> Hence, as far as the charter is concerned, I'm fine with=20 >>>>>>>>>>>> transferring rules "between" the MN and HA without=20 >>>>>>>>>>>> mentioning directions. >>>>>>>>>>>>=20 >>>>>>>>>>>> Nevertheless, we still need to agree on identifying the=20 >>>>>>>>>>>> requirement for the solution. And when it comes to this,=20 >>>>>>>>>>>> I'm strongly against voting and I'll practice this by=20 >>>>>>>>>>>> explaining in this email why I think rules can not be=20 >>>>>>>>>>>> transferred from the HA to the MN and that the only=20 >>>>>>>>>>>> direction that makes sense in MIP is >>>>>>>>>>>> MN->HA. I'll deliberately ignore arguments like "some=20 >>>>>>>>>>>> MN->people want >>>>>>>>>>>> this" or "an SDO wants this". They fall under the=20 >>>>>>>>>>>> "meaningless words" >>>>>>>>>>>> category and I'm incapable of discussing them because they=20 >>>>>>>>>>>> come with voting attitudes. They all need to be justified=20 >>>>>>>>>>>> if the WG wants to have a technical _discussion_. >>>>>>>>>>>>=20 >>>>>>>>>>>> Here are my reasons: >>>>>>>>>>>>=20 >>>>>>>>>>>> 1. The HA does not know whether a CoA is tied to a certain=20 >>>>>>>>>>>> access technology. It is one thing for the HA to send a=20 >>>>>>>>>>>> message saying "forward port 80 traffic on a wifi link" (a >>>>>>>>>>>> policy) and a completely different thing to say "forward=20 >>>>>>>>>>>> port 80 traffic using CoA 3ffe::1" >>>>>>>>>>>> (a rule). >>>>>>>>>>>>=20 >>>>>>>>>>>> 2. You might argue that the HA can be told by the MN that >>>>>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem = now? >>>>>>>>>>>> The problem is that the HA has no idea about dynamic=20 >>>>>>>>>>>> changes on that wifi link. It doesn't know if it's=20 >>>>>>>>>>>> congested, it doesn't know what application is using port=20 >>>>>>>>>>>> 80 (it doesn't have to be web >>>>>>>>>>>> traffic) or port 8000 for that matter and doesn't even know = >>>>>>>>>>>> if the AP of that wifi link works at all. >>>>>>>>>>>> Finally, it >>>>>>>>>>>> doesn't know the user's policies or other admin policies=20 >>>>>>>>>>>> for that MN. >>>>>>>>>>>> This type of information needs to be sent regularly because = >>>>>>>>>>>> it changes all the time and requires serious cross layer=20 >>>>>>>>>>>> integration including sometimes layer 8 integration! It's=20 >>>>>>>>>>>> completely impractical. >>>>>>>>>>>>=20 >>>>>>>>>>>> 3. If the HA installed rules in the MN, what happens if the = >>>>>>>>>>>> MN wants to change those rules. Say the wifi link went=20 >>>>>>>>>>>> down, or the MN's wifi interface went down and it wants to=20 >>>>>>>>>>>> move that traffic to another interface. Would the HA reject = >>>>>>>>>>>> such move? >>>>>>>>>>>> Does the MN have to justify to the HA why it needs to move=20 >>>>>>>>>>>> traffic? Does that involve writing a letter perhaps? >>>>>>>>>>>> If you say "well in that case, the HA should let the MN=20 >>>>>>>>>>>> move the traffic" >>>>>>>>>>>> then I'll ask you: what's the point of having the HA=20 >>>>>>>>>>>> install this stuff if it has no authority and how does it=20 >>>>>>>>>>>> know the reason for the MN's movement of the flow? >>>>>>>>>>>> The way to control how users do things is to incentivise=20 >>>>>>>>>>>> them with charging models and show them that things work=20 >>>>>>>>>>>> better on certain technologies, not by installing rules=20 >>>>>>>>>>>> that can't be followed. It's a broken mindset and we've=20 >>>>>>>>>>>> known that it's broken for a long time. >>>>>>>>>>>>=20 >>>>>>>>>>>> 4. Some people mentioned that the HA should be able to=20 >>>>>>>>>>>> revoke flows on the MN. I'm perfectly fine with that, just=20 >>>>>>>>>>>> extend the binding revocation draft to handle flows and the = >>>>>>>>>>>> rest is pretty straight forward. >>>>>>>>>>>>=20 >>>>>>>>>>>> Finally, I'll indulge in a true story that happened to me a = >>>>>>>>>>>> few years ago when I found that my wifi link wasn't working = >>>>>>>>>>>> in a hotel (no >>>>>>>>>>>> radio) >>>>>>>>>>>> and called the help desk. He insisted that the link was up=20 >>>>>>>>>>>> an I insisted that it wasn't. When I asked him to tell me=20 >>>>>>>>>>>> how he knows the link is up he said: I can ping the AP! Of=20 >>>>>>>>>>>> course after another >>>>>>>>>>>> 5 minutes of trying to convince him that pinging the AP=20 >>>>>>>>>>>> doesn't mean the radio is actually working he sent someone=20 >>>>>>>>>>>> to the hotel who in turn realised that the radio was not = working. >>>>>>>>>>>> For those people who want rules to be transferred from the=20 >>>>>>>>>>>> HA to the MN, please think of your HA as this help desk=20 >>>>>>>>>>>> person, i.e. >>>>>>>>>>>> it has no clue about what's happening at the other end. >>>>>>>>>>>>=20 >>>>>>>>>>>> I hope this helps with the realisation that decisions can't = >>>>>>>>>>>> be made here based on voting and that there is little merit = >>>>>>>>>>>> to transferring rules from the HA to the MN. Policies can=20 >>>>>>>>>>>> be transferred without any problems, but not rules. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hesham >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From hesham@elevatemobile.com Tue Jun 9 02:20:10 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462833A6A10 for ; Tue, 9 Jun 2009 02:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.302, 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 OqcCckKZujGi for ; Tue, 9 Jun 2009 02:20:07 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 475003A694C for ; Tue, 9 Jun 2009 02:20:06 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MDxUx-0008UX-O0; Tue, 09 Jun 2009 19:20:03 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 09 Jun 2009 19:19:57 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrAAAQQE8Q== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 09:20:10 -0000 > HA knows which CoA (according to installed bindings) have got changes in > communication due to link downgrade. => Which link?? HA knows nothing about the visited link. > By receiving rules from HA, MN will know which interfaces are affected. => Really? It doesn't know that the link it is connected to is affected until the HA tells it? Does that really make sense to you? If it does then we have to just leave it here because I can't start from this point in the discussion. > Changes may take place either on a local access (within access provider > network) or towards backbone provider, or in the worst case both. > I explained earlier that in either case MN does not know about that. In the > best case MN may know about local changes => There no "may" above. It knows about the local access. And I also explained more times than I can rememeber that changes in the HA's provider links have no bearing on CoA selection. And when you say changes in the "backbone" you seem to assume that an HA has a picture of Internet topology and knows which changes in which part of the backbone affect a specific MN interface. That makes no sense at all but that's the only way that such a change would affect a CoA selection. Hesham From yuri.ismailov@ericsson.com Tue Jun 9 02:46:58 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9963A694C for ; Tue, 9 Jun 2009 02:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.106 X-Spam-Level: X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 dCNuVdu79vR6 for ; Tue, 9 Jun 2009 02:46:58 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D62293A67F2 for ; Tue, 9 Jun 2009 02:46:55 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9cae00000140d-3f-4a2e2f869dba Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 0E.D1.05133.68F2E2A4; Tue, 9 Jun 2009 11:46:47 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 11:46:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Jun 2009 11:46:39 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrAAAQQE8QAAMm/g References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 09 Jun 2009 09:46:40.0288 (UTC) FILETIME=[30573200:01C9E8E7] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 09:46:58 -0000 =20 -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Tuesday, June 09, 2009 11:20 AM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings > HA knows which CoA (according to installed bindings) have got changes=20 > in communication due to link downgrade. =3D> Which link?? HA knows nothing about the visited link. I assume that traffic from/to MN (apart from RO mode) passes through HA, which is offered by my home network access provider, whichever is chosen if multiple exist. HA knows whether downgrade policies were applied by the access provider either inside access network (less probable, but possible) or towards backbone provider. This has nothing to do with visited link. > By receiving rules from HA, MN will know which interfaces are affected. =3D> Really? It doesn't know that the link it is connected to is = affected until the HA tells it? Does that really make sense to you? If it does then we have to just leave it here because I can't start from this point in the discussion. HA does not tell about the link MN connected to. As you said HA can not know about visited link. It knows about Home network and connection towards backbone. This is where policies are applied (e.g. traffic shaping) > Changes may take place either on a local access (within access=20 > provider > network) or towards backbone provider, or in the worst case both. > I explained earlier that in either case MN does not know about that.=20 > In the best case MN may know about local changes =3D> There no "may" above. It knows about the local access. MN knows only about EXPECTED characteristics of its interfaces, not about policies applied by access provider in the access network. And I also explained more times than I can rememeber that changes in the HA's provider links have no bearing on CoA selection. And when you say changes in the "backbone" you seem to assume that an HA has a picture of Internet topology and knows which changes in which part of the backbone affect a specific MN interface. That makes no sense at all but that's the only way that such a change would affect a CoA selection. Do not revert my words. I said that HA knows whether, for example, traffic shaping is applied. This does not have to do with changes in the backbone or knowledge of the Internet topology. This information sets the upper limit on what an interface can expect. Let's say traffic shaping will give you 64Kbs and what MN knows is that it is connected over 54Mbs WLAN and MN will keep going with already running flows and select interfaces for new flows with 54Mbs in mind. Yuri Hesham From hesham@elevatemobile.com Tue Jun 9 03:08:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04F53A6B8E for ; Tue, 9 Jun 2009 03:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.878 X-Spam-Level: X-Spam-Status: No, score=-2.878 tagged_above=-999 required=5 tests=[AWL=-0.279, 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 qwA-1lH902ba for ; Tue, 9 Jun 2009 03:08:24 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 9A3BA3A67F2 for ; Tue, 9 Jun 2009 03:08:23 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MDyFf-0004vT-8T; Tue, 09 Jun 2009 20:08:19 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 09 Jun 2009 20:08:12 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrAAAQQE8QAAMm/gAAF89IA= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 10:08:25 -0000 > > => Which link?? HA knows nothing about the visited link. > I assume that traffic from/to MN (apart from RO mode) passes through HA, > which is offered by my home network access provider, whichever is chosen > if multiple exist. HA knows whether downgrade policies were applied by > the access provider either inside access network (less probable, but > possible) or towards backbone provider. This has nothing to do with > visited link. => Good, so you're not talking about the visited link. Let's underscore this fact. Now, what happens in those other links "near" the HA (upstream or downstrean) has nothing to do with CoA selection. > >> By receiving rules from HA, MN will know which interfaces are > affected. > > => Really? It doesn't know that the link it is connected to is affected > until the HA tells it? Does that really make sense to you? If it does > then we have to just leave it here because I can't start from this point > in the discussion. > > HA does not tell about the link MN connected to. As you said HA can not > know about visited link. It knows about Home network and connection > towards backbone. This is where policies are applied (e.g. traffic > shaping) => Great. So see my answer above. > >> Changes may take place either on a local access (within access >> provider >> network) or towards backbone provider, or in the worst case both. >> I explained earlier that in either case MN does not know about that. >> In the best case MN may know about local changes > > => There no "may" above. It knows about the local access. > > MN knows only about EXPECTED characteristics of its interfaces, not > about policies applied by access provider in the access network. => It knows the outcome, it doesn't care how a link became congested. Why are you assuming the HA knows about those policies done by the visited provider anyway? Are you assuming the MN and HA are always under the same admin domain? I hope not. > > And I also explained more times than I can rememeber that changes in the > HA's provider links have no bearing on CoA selection. And when you say > changes in the "backbone" you seem to assume that an HA has a picture of > Internet topology and knows which changes in which part of the backbone > affect a specific MN interface. That makes no sense at all but that's > the only way that such a change would affect a CoA selection. > > Do not revert my words. I said that HA knows whether, for example, > traffic shaping is applied. This does not have to do with changes in the > backbone or knowledge of the Internet topology. This information sets > the upper limit on what an interface can expect. => No no no. It sets the upper limit for THAT HoA being used. You're not responding to my point which is stated in every email. There is no consequences on the CoA/interface selection by the change in the HA's upstream or HA interfaces policies, traffic shaping, or whatever you think will happen. Let's say traffic > shaping will give you 64Kbs and what MN knows is that it is connected > over 54Mbs WLAN and MN will keep going with already running flows and > select interfaces for new flows with 54Mbs in mind. => Of course, and if it changes CoA why would that 64k link suddenly become 54M?? It's the same HA and the same HoA. On the other hand, if that shaping was associated with one HA or one home prefix on that HA then changing the HoA can make a difference. Hesham > > Yuri > > Hesham > > From yuri.ismailov@ericsson.com Tue Jun 9 03:52:38 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32613A6BD7 for ; Tue, 9 Jun 2009 03:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.067 X-Spam-Level: X-Spam-Status: No, score=-7.067 tagged_above=-999 required=5 tests=[AWL=-0.818, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 LOABvnSbQGIL for ; Tue, 9 Jun 2009 03:52:37 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 402403A6961 for ; Tue, 9 Jun 2009 03:52:36 -0700 (PDT) X-AuditID: c1b4fb3e-b7b2dae00000205f-86-4a2e3eec62f4 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id DF.05.08287.CEE3E2A4; Tue, 9 Jun 2009 12:52:29 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 12:52:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Jun 2009 12:52:25 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrAAAQQE8QAAMm/gAAF89IAAAUTo4A== References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 09 Jun 2009 10:52:26.0938 (UTC) FILETIME=[60BA31A0:01C9E8F0] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 10:52:38 -0000 Hesham, Re-read my assumptions please. In my example and in reality traffic shaping is applied per subscription, if MN connected with two different interfaces does not mean that the quota exceeded on both. One may exceed but not the other. I wrote that this has nothing to do with aggregated traffic. The rest see inline. -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Tuesday, June 09, 2009 12:08 PM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings >=20 > =3D> Which link?? HA knows nothing about the visited link. > I assume that traffic from/to MN (apart from RO mode) passes through=20 > HA, which is offered by my home network access provider, whichever is=20 > chosen if multiple exist. HA knows whether downgrade policies were=20 > applied by the access provider either inside access network (less=20 > probable, but > possible) or towards backbone provider. This has nothing to do with=20 > visited link. =3D> Good, so you're not talking about the visited link. Let's = underscore this fact. Now, what happens in those other links "near" the HA (upstream or downstrean) has nothing to do with CoA selection. This is exactly what matters, because this is place where policies are applied. >=20 >> By receiving rules from HA, MN will know which interfaces are > affected. >=20 > =3D> Really? It doesn't know that the link it is connected to is=20 > affected until the HA tells it? Does that really make sense to you? If > it does then we have to just leave it here because I can't start from=20 > this point in the discussion. >=20 > HA does not tell about the link MN connected to. As you said HA can=20 > not know about visited link. It knows about Home network and=20 > connection towards backbone. This is where policies are applied (e.g.=20 > traffic > shaping) =3D> Great. So see my answer above. I've seen and can only confirm that that policies are applied at home network, where HA can and will know about that. >=20 >> Changes may take place either on a local access (within access=20 >> provider >> network) or towards backbone provider, or in the worst case both. >> I explained earlier that in either case MN does not know about that. >> In the best case MN may know about local changes >=20 > =3D> There no "may" above. It knows about the local access. >=20 > MN knows only about EXPECTED characteristics of its interfaces, not=20 > about policies applied by access provider in the access network. =3D> It knows the outcome, it doesn't care how a link became congested. Why are you assuming the HA knows about those policies done by the visited provider anyway? Are you assuming the MN and HA are always under the same admin domain? I hope not. Never said that policies are applied by visited provider, but this is an interesting point, probably does not have much to do with interface selection as long as this knowledge become available. >=20 > And I also explained more times than I can rememeber that changes in=20 > the HA's provider links have no bearing on CoA selection. And when you > say changes in the "backbone" you seem to assume that an HA has a=20 > picture of Internet topology and knows which changes in which part of=20 > the backbone affect a specific MN interface. That makes no sense at=20 > all but that's the only way that such a change would affect a CoA selection. >=20 > Do not revert my words. I said that HA knows whether, for example,=20 > traffic shaping is applied. This does not have to do with changes in=20 > the backbone or knowledge of the Internet topology. This information=20 > sets the upper limit on what an interface can expect. =3D> No no no. It sets the upper limit for THAT HoA being used. You're = not responding to my point which is stated in every email. There is no consequences on the CoA/interface selection by the change in the HA's upstream or HA interfaces policies, traffic shaping, or whatever you think will happen. =20 Let's say traffic > shaping will give you 64Kbs and what MN knows is that it is connected=20 > over 54Mbs WLAN and MN will keep going with already running flows and=20 > select interfaces for new flows with 54Mbs in mind. =3D> Of course, and if it changes CoA why would that 64k link suddenly become 54M?? It's the same HA and the same HoA. On the other hand, if that shaping was associated with one HA or one home prefix on that HA then changing the HoA can make a difference. As wrote, above and earlier traffic shaping is not performed for aggregated traffic but on subscription basis. /yuri Hesham >=20 > Yuri >=20 > Hesham >=20 >=20 From hesham@elevatemobile.com Tue Jun 9 04:01:22 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96C43A6A6F for ; Tue, 9 Jun 2009 04:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.858 X-Spam-Level: X-Spam-Status: No, score=-2.858 tagged_above=-999 required=5 tests=[AWL=-0.259, 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 ZmlYWg4VKOL5 for ; Tue, 9 Jun 2009 04:01:22 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 0CE6B3A6961 for ; Tue, 9 Jun 2009 04:01:21 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MDz4u-00071o-ES; Tue, 09 Jun 2009 21:01:18 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 09 Jun 2009 21:01:09 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrAAAQQE8QAAMm/gAAF89IAAAUTo4AAAlIEQ In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 11:01:23 -0000 > Hesham, > Re-read my assumptions please. In my example and in reality traffic > shaping is applied per subscription, if MN connected with two different > interfaces does not mean that the quota exceeded on both. One may exceed > but not the other. I wrote that this has nothing to do with aggregated > traffic. => How can you apply traffic shaping based on a CoA? This a flawed way of doing it. Not to mention, there is no practical or charging reason for doing that. If it's per subscriber as you say then it's done per HoA not per CoA. In your scenario traffic shaping would fail miserably if the MN didn't use flow binding. I.e., if a 3775 MN sends a BU with CoA1, what would your traffic shaping function do then? >> I assume that traffic from/to MN (apart from RO mode) passes through >> HA, which is offered by my home network access provider, whichever is >> chosen if multiple exist. HA knows whether downgrade policies were >> applied by the access provider either inside access network (less >> probable, but >> possible) or towards backbone provider. This has nothing to do with >> visited link. > > => Good, so you're not talking about the visited link. Let's underscore > this fact. Now, what happens in those other links "near" the HA > (upstream or > downstrean) has nothing to do with CoA selection. > > This is exactly what matters, because this is place where policies are > applied. => What exactly matters? I have no idea what you mean above. > > => Great. So see my answer above. > I've seen and can only confirm that that policies are applied at home > network, where HA can and will know about that. => Yuri, what you're saying above is factually wrong. No traffic shaping in the home network can rely on a CoA. It's just wrong, not a matter of opinion. It's almost like you don't know that the CoA doesn't even appear upstream of the HA. And if the HA is doing the shaping it will fail as I described above. > Let's say traffic >> shaping will give you 64Kbs and what MN knows is that it is connected >> over 54Mbs WLAN and MN will keep going with already running flows and >> select interfaces for new flows with 54Mbs in mind. > > => Of course, and if it changes CoA why would that 64k link suddenly > become 54M?? It's the same HA and the same HoA. On the other hand, if > that shaping was associated with one HA or one home prefix on that HA > then changing the HoA can make a difference. > > As wrote, above and earlier traffic shaping is not performed for > aggregated traffic but on subscription basis. => Now I'm convinced that you don't understand that subscription != CoA. This is a fact. Hesham > > /yuri > > Hesham > >> >> Yuri >> >> Hesham >> >> > > From yuri.ismailov@ericsson.com Tue Jun 9 05:02:01 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EE6D3A68FA for ; Tue, 9 Jun 2009 05:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.032 X-Spam-Level: X-Spam-Status: No, score=-7.032 tagged_above=-999 required=5 tests=[AWL=-0.783, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 gav6zQjTq91t for ; Tue, 9 Jun 2009 05:02:00 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9ACCC3A6862 for ; Tue, 9 Jun 2009 05:01:59 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9cae00000140d-e5-4a2e4f3b038b Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 4C.B2.05133.B3F4E2A4; Tue, 9 Jun 2009 14:02:03 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 14:02:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Jun 2009 14:02:02 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrAAAQQE8QAAMm/gAAF89IAAAUTo4AAAlIEQAAG4A/A= References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 09 Jun 2009 12:02:03.0485 (UTC) FILETIME=[1A24B0D0:01C9E8FA] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 12:02:01 -0000 =20 -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Tuesday, June 09, 2009 1:01 PM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings > Hesham, > Re-read my assumptions please. In my example and in reality traffic=20 > shaping is applied per subscription, if MN connected with two=20 > different interfaces does not mean that the quota exceeded on both.=20 > One may exceed but not the other. I wrote that this has nothing to do=20 > with aggregated traffic. =3D> How can you apply traffic shaping based on a CoA? This a flawed way of doing it. Not to mention, there is no practical or charging reason for doing that. If it's per subscriber as you say then it's done per HoA not per CoA. In your scenario traffic shaping would fail miserably if the MN didn't use flow binding. I.e., if a 3775 MN sends a BU with CoA1, what would your traffic shaping function do then? That means that Home access provider and consequently HA do not know which mobile and on which interface sends traffic. At the moment (no HA deployed) an access provider has means for that, not necessarily IP addresses identify that. When MN sends binding update, it's not only IP addresses involved. There is an authentication procedure as well. This is why actual CoA does not matter for knowing which subscription is that. When it comes to mobile networks then this knowledge is explicit because obtained through the mobile and made known for home operator. >> I assume that traffic from/to MN (apart from RO mode) passes through=20 >> HA, which is offered by my home network access provider, whichever is >> chosen if multiple exist. HA knows whether downgrade policies were=20 >> applied by the access provider either inside access network (less=20 >> probable, but >> possible) or towards backbone provider. This has nothing to do with=20 >> visited link. >=20 > =3D> Good, so you're not talking about the visited link. Let's=20 > underscore this fact. Now, what happens in those other links "near"=20 > the HA (upstream or > downstrean) has nothing to do with CoA selection. >=20 > This is exactly what matters, because this is place where policies are > applied. =3D> What exactly matters? I have no idea what you mean above. Because HA knows about applied policies and can inform MN about that in the form of rules. >=20 > =3D> Great. So see my answer above. > I've seen and can only confirm that that policies are applied at home=20 > network, where HA can and will know about that. =3D> Yuri, what you're saying above is factually wrong. No traffic = shaping in the home network can rely on a CoA. It's just wrong, not a matter of opinion. It's almost like you don't know that the CoA doesn't even appear upstream of the HA. And if the HA is doing the shaping it will fail as I described above. True, traffic shaping relies on subscription. > Let's say traffic >> shaping will give you 64Kbs and what MN knows is that it is connected >> over 54Mbs WLAN and MN will keep going with already running flows and >> select interfaces for new flows with 54Mbs in mind. >=20 > =3D> Of course, and if it changes CoA why would that 64k link suddenly = > become 54M?? It's the same HA and the same HoA. On the other hand, if=20 > that shaping was associated with one HA or one home prefix on that HA=20 > then changing the HoA can make a difference. >=20 > As wrote, above and earlier traffic shaping is not performed for=20 > aggregated traffic but on subscription basis. =3D> Now I'm convinced that you don't understand that subscription !=3D = CoA. I'm convinced that subscription !=3D CoA, which may change more often = than one changes subscription This is a fact. ????? The fact is something obvious, as you see in my answer the fact is the opposite. Yuri Hesham >=20 > /yuri >=20 > Hesham >=20 >>=20 >> Yuri >>=20 >> Hesham >>=20 >>=20 >=20 >=20 From hesham@elevatemobile.com Tue Jun 9 05:16:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF8D73A6E36 for ; Tue, 9 Jun 2009 05:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.841 X-Spam-Level: X-Spam-Status: No, score=-2.841 tagged_above=-999 required=5 tests=[AWL=-0.242, 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 TdwtzipPj5hs for ; Tue, 9 Jun 2009 05:16:12 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 749023A6E35 for ; Tue, 9 Jun 2009 05:16:11 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1ME0FM-0007pp-4z; Tue, 09 Jun 2009 22:16:08 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 09 Jun 2009 22:16:03 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrAAAQQE8QAAMm/gAAF89IAAAUTo4AAAlIEQAAG4A/AAAOWmQA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 12:16:13 -0000 > => How can you apply traffic shaping based on a CoA? This a flawed way > of doing it. Not to mention, there is no practical or charging reason > for doing that. If it's per subscriber as you say then it's done per HoA > not per CoA. > In your scenario traffic shaping would fail miserably if the MN didn't > use flow binding. I.e., if a 3775 MN sends a BU with CoA1, what would > your traffic shaping function do then? > > That means that Home access provider and consequently HA do not know > which mobile and on which interface sends traffic. => Bingo, therefore your shaping scenario falls apart, which is a good thing because it's broken. A solid per-subscriber shaping scenario in the home network would use the HoA to identify packets of course. > At the moment (no HA deployed) an access provider has means for that, > not necessarily IP addresses identify that. > When MN sends binding update, it's not only IP addresses involved. There > is an authentication procedure as well. This is why actual CoA does not > matter for knowing which subscription is that. When it comes to mobile > networks then this knowledge is explicit because obtained through the > mobile and made known for home operator. => You keep contradicting yourself. Previously you said that traffic shaping affects the CoA selection, which implies that you're doing policies based on the CoA. Now you're saying that you're not. There is only two options here CoA or HoA, which is it? The authentication you're referring to is based on the HoA. CoA means nothing to the HA. > => Yuri, what you're saying above is factually wrong. No traffic shaping > in the home network can rely on a CoA. It's just wrong, not a matter of > opinion. It's almost like you don't know that the CoA doesn't even > appear upstream of the HA. And if the HA is doing the shaping it will > fail as I described above. > True, traffic shaping relies on subscription. => Good, so there is no way the CoA can be involved in such policies. Therefore your example of informing the MN to choose a different CoA based on traffic shaping in the home network is wrong. > > => Now I'm convinced that you don't understand that subscription != CoA. > I'm convinced that subscription != CoA, which may change more often than > one changes subscription => Great then you should not be proposing that the HA sends hints for the MN to change it's CoA based on traffic shaping which takes place on the basis of subscription. If you want to map a subscription to an IP packet you would map it to the HoA. There is nothing else in the packet that can be mapped for this purpose. > > > This is a fact. > ????? The fact is something obvious, as you see in my answer the fact is > the opposite. => It's pretty obvious that you can't use a CoA for what you're doing. It's also a FACT that the authentication you refer to at the beginning is based on the HoA. I think if you want to progress this further you should go through the exercise of writing down a draft with what you're proposing. I'm pretty sure you will find some fundamental holes in the scenario you mentioned. Hesham > > Yuri > > Hesham > >> >> /yuri >> >> Hesham >> >>> >>> Yuri >>> >>> Hesham >>> >>> >> >> > > From yuri.ismailov@ericsson.com Tue Jun 9 05:52:43 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157263A6A0C for ; Tue, 9 Jun 2009 05:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 Ujo-sjoCxXtb for ; Tue, 9 Jun 2009 05:52:42 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 8BE963A6891 for ; Tue, 9 Jun 2009 05:52:41 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9cae00000140d-18-4a2e5b1de038 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id C8.B8.05133.D1B5E2A4; Tue, 9 Jun 2009 14:52:45 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 14:52:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Jun 2009 14:52:42 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrAAAQQE8QAAMm/gAAF89IAAAUTo4AAAlIEQAAG4A/AAAOWmQAAAFuHg References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 09 Jun 2009 12:52:42.0974 (UTC) FILETIME=[2DD1E7E0:01C9E901] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 12:52:43 -0000 Hesham, Please read what I'm writing, otherwise it gets really funny you answer your own questions See below -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Tuesday, June 09, 2009 2:16 PM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings > =3D> How can you apply traffic shaping based on a CoA? This a flawed = way > of doing it. Not to mention, there is no practical or charging reason=20 > for doing that. If it's per subscriber as you say then it's done per=20 > HoA not per CoA. > In your scenario traffic shaping would fail miserably if the MN didn't > use flow binding. I.e., if a 3775 MN sends a BU with CoA1, what would=20 > your traffic shaping function do then? >=20 > That means that Home access provider and consequently HA do not know=20 > which mobile and on which interface sends traffic. =3D> Bingo, therefore your shaping scenario falls apart, which is a good thing because it's broken. A solid per-subscriber shaping scenario in the home network would use the HoA to identify packets of course. I hope you simply missunderstood the above:-), which says that the meaning follows from what you wrote, but not from what I'm saying. > At the moment (no HA deployed) an access provider has means for that,=20 > not necessarily IP addresses identify that. > When MN sends binding update, it's not only IP addresses involved.=20 > There is an authentication procedure as well. This is why actual CoA=20 > does not matter for knowing which subscription is that. When it comes=20 > to mobile networks then this knowledge is explicit because obtained=20 > through the mobile and made known for home operator. =3D> You keep contradicting yourself. Previously you said that traffic shaping affects the CoA selection, which implies that you're doing policies based on the CoA. Now you're saying that you're not. There is only two options here CoA or HoA, which is it? The authentication you're referring to is based on the HoA. CoA means nothing to the HA. Please refer to my text where I said that traffic shaping affects CoA. During all discussion I stress the fact that it is subscription related. Another thing is that interfaces in the middle of discussion, not any CoA. > =3D> Yuri, what you're saying above is factually wrong. No traffic=20 > shaping in the home network can rely on a CoA. It's just wrong, not a=20 > matter of opinion. It's almost like you don't know that the CoA=20 > doesn't even appear upstream of the HA. And if the HA is doing the=20 > shaping it will fail as I described above. > True, traffic shaping relies on subscription. =3D> Good, so there is no way the CoA can be involved in such policies. Therefore your example of informing the MN to choose a different CoA based on traffic shaping in the home network is wrong. And again we are discussing choice of interfaces, not CoA. >=20 > =3D> Now I'm convinced that you don't understand that subscription = !=3D CoA. > I'm convinced that subscription !=3D CoA, which may change more often=20 > than one changes subscription =3D> Great then you should not be proposing that the HA sends hints for the MN to change it's CoA based on traffic shaping which takes place on the basis of subscription. If you want to map a subscription to an IP packet you would map it to the HoA. There is nothing else in the packet that can be mapped for this purpose. Since we are in the context of MEXT group and discussing flow mobility and related transport of rules, CoA will be sent to MN (if CoA is a part of rules representation), but not for change of CoA, for re-evaluation of rules and eventually possible another interface selection >=20 >=20 > This is a fact. > ????? The fact is something obvious, as you see in my answer the fact=20 > is the opposite. =3D> It's pretty obvious that you can't use a CoA for what you're doing. It's also a FACT that the authentication you refer to at the beginning is based on the HoA. According to my knowledge authentication starts before any address is configured on interfaces, not HoA either. I think if you want to progress this further you should go through the exercise of writing down a draft with what you're proposing. I'm pretty sure you will find some fundamental holes in the scenario you mentioned. How is that possible to find holes in the fact of transporting rules from HA to MN. All you found so far is that this is useless information, but I explained why not. Hesham >=20 > Yuri >=20 > Hesham >=20 >>=20 >> /yuri >>=20 >> Hesham >>=20 >>>=20 >>> Yuri >>>=20 >>> Hesham >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From hesham@elevatemobile.com Tue Jun 9 06:04:56 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7374A3A6C7C for ; Tue, 9 Jun 2009 06:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.825 X-Spam-Level: X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[AWL=-0.226, 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 v4HZMS2oyCNG for ; Tue, 9 Jun 2009 06:04:55 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 4A18D3A68A4 for ; Tue, 9 Jun 2009 06:04:54 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1ME10W-0001l8-7F; Tue, 09 Jun 2009 23:04:52 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 09 Jun 2009 23:04:47 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrAAAQQE8QAAMm/gAAF89IAAAUTo4AAAlIEQAAG4A/AAAOWmQAAAFuHgAAGc1aA= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 13:04:56 -0000 >> for doing that. If it's per subscriber as you say then it's done per >> HoA not per CoA. >> In your scenario traffic shaping would fail miserably if the MN didn't > >> use flow binding. I.e., if a 3775 MN sends a BU with CoA1, what would >> your traffic shaping function do then? >> >> That means that Home access provider and consequently HA do not know >> which mobile and on which interface sends traffic. > > => Bingo, therefore your shaping scenario falls apart, which is a good > thing because it's broken. A solid per-subscriber shaping scenario in > the home network would use the HoA to identify packets of course. > > I hope you simply missunderstood the above:-), which says that the > meaning follows from what you wrote, but not from what I'm saying. => I know the meaning of what I wrote, it's not a debating society, I'm trying to explain to you that what I wrote means your traffic shaping assumptions are wrong. > => You keep contradicting yourself. Previously you said that traffic > shaping affects the CoA selection, which implies that you're doing > policies based on the CoA. Now you're saying that you're not. There is > only two options here CoA or HoA, which is it? > The authentication you're referring to is based on the HoA. CoA means > nothing to the HA. > > Please refer to my text where I said that traffic shaping affects CoA. => It doesn't. Write it down on a piece of paper and trace the packets yourself. It's a broken scenario. > During all discussion I stress the fact that it is subscription related. => And you also said that you understand that subscription and CoA are not related. So... > Another thing is that interfaces in the middle of discussion, not any > CoA. > >> => Yuri, what you're saying above is factually wrong. No traffic >> shaping in the home network can rely on a CoA. It's just wrong, not a >> matter of opinion. It's almost like you don't know that the CoA >> doesn't even appear upstream of the HA. And if the HA is doing the >> shaping it will fail as I described above. > >> True, traffic shaping relies on subscription. > > => Good, so there is no way the CoA can be involved in such policies. > Therefore your example of informing the MN to choose a different CoA > based on traffic shaping in the home network is wrong. > > And again we are discussing choice of interfaces, not CoA. => Oh come on, it's impossible to have a discussion like this. Interface maps to CoA, there is no interface in the packet on the wire. > => Great then you should not be proposing that the HA sends hints for > the MN to change it's CoA based on traffic shaping which takes place on > the basis of subscription. If you want to map a subscription to an IP > packet you would map it to the HoA. There is nothing else in the packet > that can be mapped for this purpose. > > Since we are in the context of MEXT group and discussing flow mobility > and related transport of rules, CoA will be sent to MN (if CoA is a part > of rules representation), but not for change of CoA, for re-evaluation > of rules and eventually possible another interface selection => Ok please write your scenario, which is the basis for your motives in a draft. This makes no sense to me. > => It's pretty obvious that you can't use a CoA for what you're doing. > It's also a FACT that the authentication you refer to at the beginning > is based on the HoA. > > According to my knowledge authentication starts before any address is > configured on interfaces, not HoA either. => Wrong. If the HoA is allocated dynamically it is done during IKE authentication, if it's static it is allocated before the authentication. See RFCs 3775/6 and 4977. > > I think if you want to progress this further you should go through the > exercise of writing down a draft with what you're proposing. I'm pretty > sure you will find some fundamental holes in the scenario you mentioned. > > How is that possible to find holes in the fact of transporting rules > from HA to MN. All you found so far is that this is useless information, > but I explained why not. => Ok if you think it's correct please put this scenario in your draft. Hesham From yuri.ismailov@ericsson.com Tue Jun 9 06:28:26 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0EA3A686A for ; Tue, 9 Jun 2009 06:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.969 X-Spam-Level: X-Spam-Status: No, score=-6.969 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 oV8Vt+pkRRmu for ; Tue, 9 Jun 2009 06:28:26 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4F43A3A659B for ; Tue, 9 Jun 2009 06:28:25 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9cae00000140d-0e-4a2e637dfd2c Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 96.3D.05133.D736E2A4; Tue, 9 Jun 2009 15:28:29 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 15:28:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Jun 2009 15:28:27 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrAAAQQE8QAAMm/gAAF89IAAAUTo4AAAlIEQAAG4A/AAAOWmQAAAFuHgAAGc1aAAAELVEA== References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 09 Jun 2009 13:28:28.0995 (UTC) FILETIME=[2CF2B930:01C9E906] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 13:28:27 -0000 Hesham,=20 Once in the discussion we were at the point when you requested examples, scenarious, etc I provided all what is needed. Now we are back to the same point. I'm not a part of debating society, rather engineering and my discussion is not directed to you personally. Sorry but I've got an impression that you took it this way. I'm discussing support for flow mobility, nothing else. There is another point I've been thinking about - route optimization mode. Here I probably need some help in understanding whether I see it the right way or not. I consider the following situation: two mobile IP hosts communicate to each other in RO mode, and both have support for multi-access and flow mobility and both equipped with multiple interfaces. As far as I understand there is a need to send routing rules between them. It could be one, another or both exchanging the rules. If this is the case, does that mean that an MN must be capable of receiving rules. If so, then it does not matter where the rules come from. It looks like that the need for that functionality is anyway there. Is that correct understanding? /yuri -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Tuesday, June 09, 2009 3:05 PM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings >> for doing that. If it's per subscriber as you say then it's done per=20 >> HoA not per CoA. >> In your scenario traffic shaping would fail miserably if the MN=20 >> didn't >=20 >> use flow binding. I.e., if a 3775 MN sends a BU with CoA1, what would >> your traffic shaping function do then? >>=20 >> That means that Home access provider and consequently HA do not know=20 >> which mobile and on which interface sends traffic. >=20 > =3D> Bingo, therefore your shaping scenario falls apart, which is a = good > thing because it's broken. A solid per-subscriber shaping scenario in=20 > the home network would use the HoA to identify packets of course. >=20 > I hope you simply missunderstood the above:-), which says that the=20 > meaning follows from what you wrote, but not from what I'm saying. =3D> I know the meaning of what I wrote, it's not a debating society, = I'm trying to explain to you that what I wrote means your traffic shaping assumptions are wrong. > =3D> You keep contradicting yourself. Previously you said that traffic = > shaping affects the CoA selection, which implies that you're doing=20 > policies based on the CoA. Now you're saying that you're not. There is > only two options here CoA or HoA, which is it? > The authentication you're referring to is based on the HoA. CoA means=20 > nothing to the HA. >=20 > Please refer to my text where I said that traffic shaping affects CoA. =3D> It doesn't. Write it down on a piece of paper and trace the packets yourself. It's a broken scenario. > During all discussion I stress the fact that it is subscription related. =3D> And you also said that you understand that subscription and CoA are not related. So... > Another thing is that interfaces in the middle of discussion, not any=20 > CoA. >=20 >> =3D> Yuri, what you're saying above is factually wrong. No traffic=20 >> shaping in the home network can rely on a CoA. It's just wrong, not a >> matter of opinion. It's almost like you don't know that the CoA=20 >> doesn't even appear upstream of the HA. And if the HA is doing the=20 >> shaping it will fail as I described above. >=20 >> True, traffic shaping relies on subscription. >=20 > =3D> Good, so there is no way the CoA can be involved in such = policies. > Therefore your example of informing the MN to choose a different CoA=20 > based on traffic shaping in the home network is wrong. >=20 > And again we are discussing choice of interfaces, not CoA. =3D> Oh come on, it's impossible to have a discussion like this. = Interface maps to CoA, there is no interface in the packet on the wire. > =3D> Great then you should not be proposing that the HA sends hints = for=20 > the MN to change it's CoA based on traffic shaping which takes place=20 > on the basis of subscription. If you want to map a subscription to an=20 > IP packet you would map it to the HoA. There is nothing else in the=20 > packet that can be mapped for this purpose. >=20 > Since we are in the context of MEXT group and discussing flow mobility > and related transport of rules, CoA will be sent to MN (if CoA is a=20 > part of rules representation), but not for change of CoA, for=20 > re-evaluation of rules and eventually possible another interface=20 > selection =3D> Ok please write your scenario, which is the basis for your motives = in a draft. This makes no sense to me. > =3D> It's pretty obvious that you can't use a CoA for what you're = doing. > It's also a FACT that the authentication you refer to at the beginning > is based on the HoA. >=20 > According to my knowledge authentication starts before any address is=20 > configured on interfaces, not HoA either. =3D> Wrong. If the HoA is allocated dynamically it is done during IKE authentication, if it's static it is allocated before the authentication. See RFCs 3775/6 and 4977. >=20 > I think if you want to progress this further you should go through the > exercise of writing down a draft with what you're proposing. I'm=20 > pretty sure you will find some fundamental holes in the scenario you mentioned. >=20 > How is that possible to find holes in the fact of transporting rules=20 > from HA to MN. All you found so far is that this is useless=20 > information, but I explained why not. =3D> Ok if you think it's correct please put this scenario in your = draft. Hesham From hesham@elevatemobile.com Tue Jun 9 06:34:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 882073A6B6E for ; Tue, 9 Jun 2009 06:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[AWL=-0.213, 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 kMNqIaSuKB1N for ; Tue, 9 Jun 2009 06:34:28 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 31A893A659B for ; Tue, 9 Jun 2009 06:34:27 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1ME1T5-0005hq-Lt; Tue, 09 Jun 2009 23:34:24 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 09 Jun 2009 23:34:16 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrAAAQQE8QAAMm/gAAF89IAAAUTo4AAAlIEQAAG4A/AAAOWmQAAAFuHgAAGc1aAAAELVEAAAxMVK In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 13:34:29 -0000 > Hesham, > Once in the discussion we were at the point when you requested examples, > scenarious, etc > I provided all what is needed. Now we are back to the same point. > > I'm not a part of debating society, rather engineering and my discussion > is not directed to you personally. Sorry but I've got an impression that > you took it this way. I'm discussing support for flow mobility, nothing > else. => No problem, we'll solve it on the chess board :). I just find it frustrating that we can't get to a common ground (which to me seems clear) but anyway, best to write a draft. > > There is another point I've been thinking about - route optimization > mode. > Here I probably need some help in understanding whether I see it the > right way or not. > I consider the following situation: two mobile IP hosts communicate to > each other in RO mode, and both have support for multi-access and flow > mobility and both equipped with multiple interfaces. > As far as I understand there is a need to send routing rules between > them. It could be one, another or both exchanging the rules. > If this is the case, does that mean that an MN must be capable of > receiving rules. If so, then it does not matter where the rules come > from. It looks like that the need for that functionality is anyway > there. > Is that correct understanding? => Well, so far we haven't seen the need for the CN to send any rules to the MN (for the MN's selections). I certainly think the MN should send the rules to the CN as described in the flow bindings draft but not the reverse direction. Hesham > > /yuri > > > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Tuesday, June 09, 2009 3:05 PM > To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of > flowbindings > > > >>> for doing that. If it's per subscriber as you say then it's done per >>> HoA not per CoA. >>> In your scenario traffic shaping would fail miserably if the MN >>> didn't >> >>> use flow binding. I.e., if a 3775 MN sends a BU with CoA1, what would > >>> your traffic shaping function do then? >>> >>> That means that Home access provider and consequently HA do not know >>> which mobile and on which interface sends traffic. >> >> => Bingo, therefore your shaping scenario falls apart, which is a good > >> thing because it's broken. A solid per-subscriber shaping scenario in >> the home network would use the HoA to identify packets of course. >> >> I hope you simply missunderstood the above:-), which says that the >> meaning follows from what you wrote, but not from what I'm saying. > > => I know the meaning of what I wrote, it's not a debating society, I'm > trying to explain to you that what I wrote means your traffic shaping > assumptions are wrong. > >> => You keep contradicting yourself. Previously you said that traffic >> shaping affects the CoA selection, which implies that you're doing >> policies based on the CoA. Now you're saying that you're not. There is > >> only two options here CoA or HoA, which is it? >> The authentication you're referring to is based on the HoA. CoA means >> nothing to the HA. >> >> Please refer to my text where I said that traffic shaping affects CoA. > > => It doesn't. Write it down on a piece of paper and trace the packets > yourself. It's a broken scenario. > >> During all discussion I stress the fact that it is subscription > related. > > => And you also said that you understand that subscription and CoA are > not related. So... > >> Another thing is that interfaces in the middle of discussion, not any >> CoA. >> >>> => Yuri, what you're saying above is factually wrong. No traffic >>> shaping in the home network can rely on a CoA. It's just wrong, not a > >>> matter of opinion. It's almost like you don't know that the CoA >>> doesn't even appear upstream of the HA. And if the HA is doing the >>> shaping it will fail as I described above. >> >>> True, traffic shaping relies on subscription. >> >> => Good, so there is no way the CoA can be involved in such policies. >> Therefore your example of informing the MN to choose a different CoA >> based on traffic shaping in the home network is wrong. >> >> And again we are discussing choice of interfaces, not CoA. > > => Oh come on, it's impossible to have a discussion like this. Interface > maps to CoA, there is no interface in the packet on the wire. > >> => Great then you should not be proposing that the HA sends hints for >> the MN to change it's CoA based on traffic shaping which takes place >> on the basis of subscription. If you want to map a subscription to an >> IP packet you would map it to the HoA. There is nothing else in the >> packet that can be mapped for this purpose. >> >> Since we are in the context of MEXT group and discussing flow mobility > >> and related transport of rules, CoA will be sent to MN (if CoA is a >> part of rules representation), but not for change of CoA, for >> re-evaluation of rules and eventually possible another interface >> selection > > => Ok please write your scenario, which is the basis for your motives in > a draft. This makes no sense to me. > >> => It's pretty obvious that you can't use a CoA for what you're doing. >> It's also a FACT that the authentication you refer to at the beginning > >> is based on the HoA. >> >> According to my knowledge authentication starts before any address is >> configured on interfaces, not HoA either. > > => Wrong. If the HoA is allocated dynamically it is done during IKE > authentication, if it's static it is allocated before the > authentication. > See RFCs 3775/6 and 4977. > >> >> I think if you want to progress this further you should go through the > >> exercise of writing down a draft with what you're proposing. I'm >> pretty sure you will find some fundamental holes in the scenario you > mentioned. >> >> How is that possible to find holes in the fact of transporting rules >> from HA to MN. All you found so far is that this is useless >> information, but I explained why not. > > => Ok if you think it's correct please put this scenario in your draft. > > Hesham > > > From yuri.ismailov@ericsson.com Tue Jun 9 07:16:12 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98493A69F2 for ; Tue, 9 Jun 2009 07:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.941 X-Spam-Level: X-Spam-Status: No, score=-6.941 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 ESHzA1h2ixn3 for ; Tue, 9 Jun 2009 07:16:11 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 314503A6996 for ; Tue, 9 Jun 2009 07:16:09 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9cae00000140d-f1-4a2e6ead6796 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 5B.12.05133.DAE6E2A4; Tue, 9 Jun 2009 16:16:13 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jun 2009 16:15:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Jun 2009 16:15:41 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrAAAQQE8QAAMm/gAAF89IAAAUTo4AAAlIEQAAG4A/AAAOWmQAAAFuHgAAGc1aAAAELVEAAAxMVKAAAU1vA= References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 09 Jun 2009 14:15:42.0316 (UTC) FILETIME=[C5BD32C0:01C9E90C] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 14:16:12 -0000 =20 -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Tuesday, June 09, 2009 3:34 PM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings > Hesham, > Once in the discussion we were at the point when you requested=20 > examples, scenarious, etc I provided all what is needed. Now we are=20 > back to the same point. >=20 > I'm not a part of debating society, rather engineering and my=20 > discussion is not directed to you personally. Sorry but I've got an=20 > impression that you took it this way. I'm discussing support for flow=20 > mobility, nothing else. =3D> No problem, we'll solve it on the chess board :). I just find it frustrating that we can't get to a common ground (which to me seems clear) but anyway, best to write a draft. Chessboard is a good thing to go for:-) Here I'm always in. Writing draft with one message (+ ack) specified, looks a bit too ambitious, does it? It's not frustrating for me it is rather suprizing that we cannot agree on, in my view, such obvious things. >=20 > There is another point I've been thinking about - route optimization=20 > mode. > Here I probably need some help in understanding whether I see it the=20 > right way or not. > I consider the following situation: two mobile IP hosts communicate to > each other in RO mode, and both have support for multi-access and flow > mobility and both equipped with multiple interfaces. > As far as I understand there is a need to send routing rules between=20 > them. It could be one, another or both exchanging the rules. > If this is the case, does that mean that an MN must be capable of=20 > receiving rules. If so, then it does not matter where the rules come=20 > from. It looks like that the need for that functionality is anyway=20 > there. > Is that correct understanding? =3D> Well, so far we haven't seen the need for the CN to send any rules = to the MN (for the MN's selections). I certainly think the MN should send the rules to the CN as described in the flow bindings draft but not the reverse direction. I specifically mentioned both MNs in the above scenario. Things get more interesting whith multimedia applications in mind, where an application often acts as a client and a server. In such case both mobiles will have to initiate communication at some point and serve as MN and CN simulteneously. (Confused by myself: is there any difference between CN and MN? Any host, even stationary computer may change address and it is allowed to have MIP with extentions on any host. In the case of multiple interfaces, even without MIP, the selection procedure should be performed anyway. So, do not really know how to distinguish between MN and CN) If such scenario is out of scope so far, then I hope at least that it is not out of scope in general. Together with the previous scenario another draft will make sense, because it will cover significant part of the work. If MEXT is not the right place for that, then as I said "one message draft" does not make sense to me, I think that small changes can be made to existing documents. Any ideas about that? Yuri Hesham >=20 > /yuri >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Tuesday, June 09, 2009 3:05 PM > To: Yuri Ismailov; Nicolas Montavont;=20 > pierrick.seite@orange-ftgroup.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Important considerations for directionality of=20 > flowbindings >=20 >=20 >=20 >>> for doing that. If it's per subscriber as you say then it's done per >>> HoA not per CoA. >>> In your scenario traffic shaping would fail miserably if the MN=20 >>> didn't >>=20 >>> use flow binding. I.e., if a 3775 MN sends a BU with CoA1, what=20 >>> would >=20 >>> your traffic shaping function do then? >>>=20 >>> That means that Home access provider and consequently HA do not know >>> which mobile and on which interface sends traffic. >>=20 >> =3D> Bingo, therefore your shaping scenario falls apart, which is a=20 >> good >=20 >> thing because it's broken. A solid per-subscriber shaping scenario in >> the home network would use the HoA to identify packets of course. >>=20 >> I hope you simply missunderstood the above:-), which says that the=20 >> meaning follows from what you wrote, but not from what I'm saying. >=20 > =3D> I know the meaning of what I wrote, it's not a debating society,=20 > I'm trying to explain to you that what I wrote means your traffic=20 > shaping assumptions are wrong. >=20 >> =3D> You keep contradicting yourself. Previously you said that = traffic=20 >> shaping affects the CoA selection, which implies that you're doing=20 >> policies based on the CoA. Now you're saying that you're not. There=20 >> is >=20 >> only two options here CoA or HoA, which is it? >> The authentication you're referring to is based on the HoA. CoA means >> nothing to the HA. >>=20 >> Please refer to my text where I said that traffic shaping affects CoA. >=20 > =3D> It doesn't. Write it down on a piece of paper and trace the = packets > yourself. It's a broken scenario. >=20 >> During all discussion I stress the fact that it is subscription > related. >=20 > =3D> And you also said that you understand that subscription and CoA = are > not related. So... >=20 >> Another thing is that interfaces in the middle of discussion, not any >> CoA. >>=20 >>> =3D> Yuri, what you're saying above is factually wrong. No traffic=20 >>> shaping in the home network can rely on a CoA. It's just wrong, not=20 >>> a >=20 >>> matter of opinion. It's almost like you don't know that the CoA=20 >>> doesn't even appear upstream of the HA. And if the HA is doing the=20 >>> shaping it will fail as I described above. >>=20 >>> True, traffic shaping relies on subscription. >>=20 >> =3D> Good, so there is no way the CoA can be involved in such = policies. >> Therefore your example of informing the MN to choose a different CoA=20 >> based on traffic shaping in the home network is wrong. >>=20 >> And again we are discussing choice of interfaces, not CoA. >=20 > =3D> Oh come on, it's impossible to have a discussion like this.=20 > Interface maps to CoA, there is no interface in the packet on the wire. >=20 >> =3D> Great then you should not be proposing that the HA sends hints = for >> the MN to change it's CoA based on traffic shaping which takes place=20 >> on the basis of subscription. If you want to map a subscription to an >> IP packet you would map it to the HoA. There is nothing else in the=20 >> packet that can be mapped for this purpose. >>=20 >> Since we are in the context of MEXT group and discussing flow=20 >> mobility >=20 >> and related transport of rules, CoA will be sent to MN (if CoA is a=20 >> part of rules representation), but not for change of CoA, for=20 >> re-evaluation of rules and eventually possible another interface=20 >> selection >=20 > =3D> Ok please write your scenario, which is the basis for your = motives=20 > in a draft. This makes no sense to me. >=20 >> =3D> It's pretty obvious that you can't use a CoA for what you're doing. >> It's also a FACT that the authentication you refer to at the=20 >> beginning >=20 >> is based on the HoA. >>=20 >> According to my knowledge authentication starts before any address is >> configured on interfaces, not HoA either. >=20 > =3D> Wrong. If the HoA is allocated dynamically it is done during IKE=20 > authentication, if it's static it is allocated before the=20 > authentication. > See RFCs 3775/6 and 4977. >=20 >>=20 >> I think if you want to progress this further you should go through=20 >> the >=20 >> exercise of writing down a draft with what you're proposing. I'm=20 >> pretty sure you will find some fundamental holes in the scenario you > mentioned. >>=20 >> How is that possible to find holes in the fact of transporting rules=20 >> from HA to MN. All you found so far is that this is useless=20 >> information, but I explained why not. >=20 > =3D> Ok if you think it's correct please put this scenario in your draft. >=20 > Hesham >=20 >=20 >=20 From rfc-editor@rfc-editor.org Tue Jun 9 17:00:39 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D13BF3A696A; Tue, 9 Jun 2009 17:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.011 X-Spam-Level: X-Spam-Status: No, score=-17.011 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 dbn8ZUxX8C9B; Tue, 9 Jun 2009 17:00:38 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id D67A43A6841; Tue, 9 Jun 2009 17:00:38 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 89AD52C791C; Tue, 9 Jun 2009 17:00:00 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090610000000.89AD52C791C@bosco.isi.edu> Date: Tue, 9 Jun 2009 17:00:00 -0700 (PDT) Cc: mext@ietf.org, rfc-editor@rfc-editor.org Subject: [MEXT] RFC 5555 on Mobile IPv6 Support for Dual Stack Hosts and Routers X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 00:00:39 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5555 Title: Mobile IPv6 Support for Dual Stack Hosts and Routers Author: H. Soliman, Ed. Status: Standards Track Date: June 2009 Mailbox: hesham@elevatemobile.com Pages: 41 Characters: 92387 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mext-nemo-v4traversal-10.txt URL: http://www.rfc-editor.org/rfc/rfc5555.txt The current Mobile IPv6 and Network Mobility (NEMO) specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the mobile node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. [STANDARDS TRACK] This document is a product of the Mobility EXTensions for IPv6 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From hesham@elevatemobile.com Tue Jun 9 17:13:05 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3213B3A6B43 for ; Tue, 9 Jun 2009 17:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] 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 FtqEDvVNwKs4 for ; Tue, 9 Jun 2009 17:13:04 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 5237F3A6B03 for ; Tue, 9 Jun 2009 17:13:03 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MEBRD-0007ut-IN for ; Wed, 10 Jun 2009 10:13:08 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Wed, 10 Jun 2009 10:13:04 +1000 From: Hesham Soliman To: Message-ID: Thread-Topic: [MEXT] RFC 5555 on Mobile IPv6 Support for Dual Stack Hosts and Routers Thread-Index: AcnpYDkMkLwbtaJoXEO53S/4orpSdw== In-Reply-To: <20090610000000.89AD52C791C@bosco.isi.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [MEXT] RFC 5555 on Mobile IPv6 Support for Dual Stack Hosts and Routers X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 00:13:05 -0000 Thanks to everyone who worked on this. It only took 5 years :). Special thanks to Christian, Karen, Pasi and George for their help with the security problems. Hesham On 10/06/09 10:00 AM, "rfc-editor@rfc-editor.org" wrote: > > A new Request for Comments is now available in online RFC libraries. > > > RFC 5555 > > Title: Mobile IPv6 Support for Dual > Stack Hosts and Routers > Author: H. Soliman, Ed. > Status: Standards Track > Date: June 2009 > Mailbox: hesham@elevatemobile.com > Pages: 41 > Characters: 92387 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-mext-nemo-v4traversal-10.txt > > URL: http://www.rfc-editor.org/rfc/rfc5555.txt > > The current Mobile IPv6 and Network Mobility (NEMO) specifications > support IPv6 only. This specification extends those standards to > allow the registration of IPv4 addresses and prefixes, respectively, > and the transport of both IPv4 and IPv6 packets over the tunnel to the > home agent. This specification also allows the mobile node to roam > over both IPv6 and IPv4, including the case where Network Address > Translation is present on the path between the mobile node and its > home agent. [STANDARDS TRACK] > > This document is a product of the Mobility EXTensions for IPv6 Working Group > of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > USC/Information Sciences Institute > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From hesham@elevatemobile.com Tue Jun 9 23:35:57 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B743A6C92 for ; Tue, 9 Jun 2009 23:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=-0.321, 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 Q4xjHnS0fMKQ for ; Tue, 9 Jun 2009 23:35:50 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 254ED3A690E for ; Tue, 9 Jun 2009 23:35:49 -0700 (PDT) Received: from [115.130.15.88] by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MEHPP-0005Qr-Hc; Wed, 10 Jun 2009 16:35:44 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Wed, 10 Jun 2009 16:35:31 +1000 From: Hesham Soliman To: Yuri Ismailov , Nicolas Montavont , Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrAAAQQE8QAAMm/gAAF89IAAAUTo4AAAlIEQAAG4A/AAAOWmQAAAFuHgAAGc1aAAAELVEAAAxMVKAAAU1vAAI5XZLA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 06:35:57 -0000 > > Chessboard is a good thing to go for:-) Here I'm always in. Writing > draft with one message (+ ack) specified, looks a bit too ambitious, > does it? => I don't think the message is the issue. The message part is always easy it's the justification for this message with concrete scenarios, triggers that lead to sending the message ....etc. > => Well, so far we haven't seen the need for the CN to send any rules to > the MN (for the MN's selections). I certainly think the MN should send > the rules to the CN as described in the flow bindings draft but not the > reverse direction. > > I specifically mentioned both MNs in the above scenario. Things get more > interesting whith multimedia applications in mind, where an application > often acts as a client and a server. In such case both mobiles will have > to initiate communication at some point and serve as MN and CN > simulteneously. (Confused by myself: is there any difference between CN > and MN? Any host, even stationary computer may change address and it is > allowed to have MIP with extentions on any host. In the case of multiple > interfaces, even without MIP, the selection procedure should be > performed anyway. So, do not really know how to distinguish between MN > and CN) > If such scenario is out of scope so far, then I hope at least that it > is not out of scope in general. Together with the previous scenario > another draft will make sense, because it will cover significant part of > the work. If MEXT is not the right place for that, then as I said "one > message draft" does not make sense to me, I think that small changes can > be made to existing documents. > > Any ideas about that? => The difference between MN and CN is a functional one and describes the context of communication in MIP. A CN receives a BU and an MN sends the BU. So being a CN or MN is not a permanent attribute. I'm not sure I understand what you want to do from the CN to the MN but I think if you write a draft this will become clearer (I hope). Hesham Hesham > > Yuri > > Hesham > >> >> /yuri >> >> >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Tuesday, June 09, 2009 3:05 PM >> To: Yuri Ismailov; Nicolas Montavont; >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of >> flowbindings >> >> >> >>>> for doing that. If it's per subscriber as you say then it's done per > >>>> HoA not per CoA. >>>> In your scenario traffic shaping would fail miserably if the MN >>>> didn't >>> >>>> use flow binding. I.e., if a 3775 MN sends a BU with CoA1, what >>>> would >> >>>> your traffic shaping function do then? >>>> >>>> That means that Home access provider and consequently HA do not know > >>>> which mobile and on which interface sends traffic. >>> >>> => Bingo, therefore your shaping scenario falls apart, which is a >>> good >> >>> thing because it's broken. A solid per-subscriber shaping scenario in > >>> the home network would use the HoA to identify packets of course. >>> >>> I hope you simply missunderstood the above:-), which says that the >>> meaning follows from what you wrote, but not from what I'm saying. >> >> => I know the meaning of what I wrote, it's not a debating society, >> I'm trying to explain to you that what I wrote means your traffic >> shaping assumptions are wrong. >> >>> => You keep contradicting yourself. Previously you said that traffic >>> shaping affects the CoA selection, which implies that you're doing >>> policies based on the CoA. Now you're saying that you're not. There >>> is >> >>> only two options here CoA or HoA, which is it? >>> The authentication you're referring to is based on the HoA. CoA means > >>> nothing to the HA. >>> >>> Please refer to my text where I said that traffic shaping affects > CoA. >> >> => It doesn't. Write it down on a piece of paper and trace the packets > >> yourself. It's a broken scenario. >> >>> During all discussion I stress the fact that it is subscription >> related. >> >> => And you also said that you understand that subscription and CoA are > >> not related. So... >> >>> Another thing is that interfaces in the middle of discussion, not any > >>> CoA. >>> >>>> => Yuri, what you're saying above is factually wrong. No traffic >>>> shaping in the home network can rely on a CoA. It's just wrong, not >>>> a >> >>>> matter of opinion. It's almost like you don't know that the CoA >>>> doesn't even appear upstream of the HA. And if the HA is doing the >>>> shaping it will fail as I described above. >>> >>>> True, traffic shaping relies on subscription. >>> >>> => Good, so there is no way the CoA can be involved in such policies. >>> Therefore your example of informing the MN to choose a different CoA >>> based on traffic shaping in the home network is wrong. >>> >>> And again we are discussing choice of interfaces, not CoA. >> >> => Oh come on, it's impossible to have a discussion like this. >> Interface maps to CoA, there is no interface in the packet on the > wire. >> >>> => Great then you should not be proposing that the HA sends hints for > >>> the MN to change it's CoA based on traffic shaping which takes place >>> on the basis of subscription. If you want to map a subscription to an > >>> IP packet you would map it to the HoA. There is nothing else in the >>> packet that can be mapped for this purpose. >>> >>> Since we are in the context of MEXT group and discussing flow >>> mobility >> >>> and related transport of rules, CoA will be sent to MN (if CoA is a >>> part of rules representation), but not for change of CoA, for >>> re-evaluation of rules and eventually possible another interface >>> selection >> >> => Ok please write your scenario, which is the basis for your motives >> in a draft. This makes no sense to me. >> >>> => It's pretty obvious that you can't use a CoA for what you're > doing. >>> It's also a FACT that the authentication you refer to at the >>> beginning >> >>> is based on the HoA. >>> >>> According to my knowledge authentication starts before any address is > >>> configured on interfaces, not HoA either. >> >> => Wrong. If the HoA is allocated dynamically it is done during IKE >> authentication, if it's static it is allocated before the >> authentication. >> See RFCs 3775/6 and 4977. >> >>> >>> I think if you want to progress this further you should go through >>> the >> >>> exercise of writing down a draft with what you're proposing. I'm >>> pretty sure you will find some fundamental holes in the scenario you >> mentioned. >>> >>> How is that possible to find holes in the fact of transporting rules >>> from HA to MN. All you found so far is that this is useless >>> information, but I explained why not. >> >> => Ok if you think it's correct please put this scenario in your > draft. >> >> Hesham >> >> >> > > From yuri.ismailov@ericsson.com Wed Jun 10 00:30:53 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8921F3A6CE9 for ; Wed, 10 Jun 2009 00:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.916 X-Spam-Level: X-Spam-Status: No, score=-6.916 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 PfYzmdK4inhM for ; Wed, 10 Jun 2009 00:30:52 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C449C3A6C79 for ; Wed, 10 Jun 2009 00:30:51 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9cae00000140d-db-4a2f61305efc Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id CF.57.05133.0316F2A4; Wed, 10 Jun 2009 09:30:56 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jun 2009 09:30:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jun 2009 09:30:54 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Important considerations for directionality of flowbindings Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrAAAQQE8QAAMm/gAAF89IAAAUTo4AAAlIEQAAG4A/AAAOWmQAAAFuHgAAGc1aAAAELVEAAAxMVKAAAU1vAAI5XZLAABwNwg References: From: "Yuri Ismailov" To: "Hesham Soliman" , "Nicolas Montavont" , X-OriginalArrivalTime: 10 Jun 2009 07:30:56.0011 (UTC) FILETIME=[6462E5B0:01C9E99D] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 07:30:53 -0000 Yep, Scenarious are pretty much clear, so should not be a problem either. /yuri=20 -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Wednesday, June 10, 2009 8:36 AM To: Yuri Ismailov; Nicolas Montavont; pierrick.seite@orange-ftgroup.com Cc: mext@ietf.org Subject: Re: [MEXT] Important considerations for directionality of flowbindings >=20 > Chessboard is a good thing to go for:-) Here I'm always in. Writing=20 > draft with one message (+ ack) specified, looks a bit too ambitious,=20 > does it? =3D> I don't think the message is the issue. The message part is always easy it's the justification for this message with concrete scenarios, triggers that lead to sending the message ....etc. > =3D> Well, so far we haven't seen the need for the CN to send any = rules=20 > to the MN (for the MN's selections). I certainly think the MN should=20 > send the rules to the CN as described in the flow bindings draft but=20 > not the reverse direction. >=20 > I specifically mentioned both MNs in the above scenario. Things get=20 > more interesting whith multimedia applications in mind, where an=20 > application often acts as a client and a server. In such case both=20 > mobiles will have to initiate communication at some point and serve as > MN and CN simulteneously. (Confused by myself: is there any difference > between CN and MN? Any host, even stationary computer may change=20 > address and it is allowed to have MIP with extentions on any host. In=20 > the case of multiple interfaces, even without MIP, the selection=20 > procedure should be performed anyway. So, do not really know how to=20 > distinguish between MN and CN) If such scenario is out of scope so=20 > far, then I hope at least that it is not out of scope in general.=20 > Together with the previous scenario another draft will make sense,=20 > because it will cover significant part of the work. If MEXT is not the > right place for that, then as I said "one message draft" does not make > sense to me, I think that small changes can be made to existing=20 > documents. >=20 > Any ideas about that? =3D> The difference between MN and CN is a functional one and describes the context of communication in MIP. A CN receives a BU and an MN sends the BU. So being a CN or MN is not a permanent attribute. I'm not sure I understand what you want to do from the CN to the MN but I think if you write a draft this will become clearer (I hope). Hesham Hesham >=20 > Yuri >=20 > Hesham >=20 >>=20 >> /yuri >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Tuesday, June 09, 2009 3:05 PM >> To: Yuri Ismailov; Nicolas Montavont;=20 >> pierrick.seite@orange-ftgroup.com >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Important considerations for directionality of=20 >> flowbindings >>=20 >>=20 >>=20 >>>> for doing that. If it's per subscriber as you say then it's done=20 >>>> per >=20 >>>> HoA not per CoA. >>>> In your scenario traffic shaping would fail miserably if the MN=20 >>>> didn't >>>=20 >>>> use flow binding. I.e., if a 3775 MN sends a BU with CoA1, what=20 >>>> would >>=20 >>>> your traffic shaping function do then? >>>>=20 >>>> That means that Home access provider and consequently HA do not=20 >>>> know >=20 >>>> which mobile and on which interface sends traffic. >>>=20 >>> =3D> Bingo, therefore your shaping scenario falls apart, which is a=20 >>> good >>=20 >>> thing because it's broken. A solid per-subscriber shaping scenario=20 >>> in >=20 >>> the home network would use the HoA to identify packets of course. >>>=20 >>> I hope you simply missunderstood the above:-), which says that the=20 >>> meaning follows from what you wrote, but not from what I'm saying. >>=20 >> =3D> I know the meaning of what I wrote, it's not a debating society, = >> I'm trying to explain to you that what I wrote means your traffic=20 >> shaping assumptions are wrong. >>=20 >>> =3D> You keep contradicting yourself. Previously you said that = traffic >>> shaping affects the CoA selection, which implies that you're doing=20 >>> policies based on the CoA. Now you're saying that you're not. There=20 >>> is >>=20 >>> only two options here CoA or HoA, which is it? >>> The authentication you're referring to is based on the HoA. CoA=20 >>> means >=20 >>> nothing to the HA. >>>=20 >>> Please refer to my text where I said that traffic shaping affects > CoA. >>=20 >> =3D> It doesn't. Write it down on a piece of paper and trace the=20 >> packets >=20 >> yourself. It's a broken scenario. >>=20 >>> During all discussion I stress the fact that it is subscription >> related. >>=20 >> =3D> And you also said that you understand that subscription and CoA=20 >> are >=20 >> not related. So... >>=20 >>> Another thing is that interfaces in the middle of discussion, not=20 >>> any >=20 >>> CoA. >>>=20 >>>> =3D> Yuri, what you're saying above is factually wrong. No traffic=20 >>>> shaping in the home network can rely on a CoA. It's just wrong, not >>>> a >>=20 >>>> matter of opinion. It's almost like you don't know that the CoA=20 >>>> doesn't even appear upstream of the HA. And if the HA is doing the=20 >>>> shaping it will fail as I described above. >>>=20 >>>> True, traffic shaping relies on subscription. >>>=20 >>> =3D> Good, so there is no way the CoA can be involved in such policies. >>> Therefore your example of informing the MN to choose a different CoA >>> based on traffic shaping in the home network is wrong. >>>=20 >>> And again we are discussing choice of interfaces, not CoA. >>=20 >> =3D> Oh come on, it's impossible to have a discussion like this. >> Interface maps to CoA, there is no interface in the packet on the > wire. >>=20 >>> =3D> Great then you should not be proposing that the HA sends hints=20 >>> for >=20 >>> the MN to change it's CoA based on traffic shaping which takes place >>> on the basis of subscription. If you want to map a subscription to=20 >>> an >=20 >>> IP packet you would map it to the HoA. There is nothing else in the=20 >>> packet that can be mapped for this purpose. >>>=20 >>> Since we are in the context of MEXT group and discussing flow=20 >>> mobility >>=20 >>> and related transport of rules, CoA will be sent to MN (if CoA is a=20 >>> part of rules representation), but not for change of CoA, for=20 >>> re-evaluation of rules and eventually possible another interface=20 >>> selection >>=20 >> =3D> Ok please write your scenario, which is the basis for your = motives >> in a draft. This makes no sense to me. >>=20 >>> =3D> It's pretty obvious that you can't use a CoA for what you're > doing. >>> It's also a FACT that the authentication you refer to at the=20 >>> beginning >>=20 >>> is based on the HoA. >>>=20 >>> According to my knowledge authentication starts before any address=20 >>> is >=20 >>> configured on interfaces, not HoA either. >>=20 >> =3D> Wrong. If the HoA is allocated dynamically it is done during IKE = >> authentication, if it's static it is allocated before the=20 >> authentication. >> See RFCs 3775/6 and 4977. >>=20 >>>=20 >>> I think if you want to progress this further you should go through=20 >>> the >>=20 >>> exercise of writing down a draft with what you're proposing. I'm=20 >>> pretty sure you will find some fundamental holes in the scenario you >> mentioned. >>>=20 >>> How is that possible to find holes in the fact of transporting rules >>> from HA to MN. All you found so far is that this is useless=20 >>> information, but I explained why not. >>=20 >> =3D> Ok if you think it's correct please put this scenario in your > draft. >>=20 >> Hesham >>=20 >>=20 >>=20 >=20 >=20 From AMUHANNA@nortel.com Wed Jun 10 10:29:00 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E22863A68A7 for ; Wed, 10 Jun 2009 10:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.719 X-Spam-Level: X-Spam-Status: No, score=-5.719 tagged_above=-999 required=5 tests=[AWL=0.880, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 NzOiR-XIdw3p for ; Wed, 10 Jun 2009 10:28:55 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 81A2F3A6AFE for ; Wed, 10 Jun 2009 10:28:54 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5AHRaP06249; Wed, 10 Jun 2009 17:27:36 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jun 2009 12:28:46 -0500 Message-ID: In-Reply-To: <7ad6d6db0906020421m2f6a9cb6xbff75a8da1b43b54@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LMA behavior for HI status unknown (was Re: Binding Revocation almost ready for IESG) Thread-Index: AcnjdFkyQx8CvVS9QxeE9a/DOkS3xwGfAL2g References: <4A16E743.5010400@wichorus.com> <7ad6d6db0906020421m2f6a9cb6xbff75a8da1b43b54@mail.gmail.com> From: "Ahmad Muhanna" To: "mext" Cc: Julien Laganier Subject: Re: [MEXT] LMA behavior for HI status unknown (was Re: Binding Revocation almost ready for IESG) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 17:29:01 -0000 Hello All, We discussed this offline and we have the following agreed upon text. = Please take a look and let us know if you have any comment, issue or = concern. We are planning for spinning a new revision by the end of the = coming weekend. Many thanks in advance! Ahmad Under section 9.1.1., the following text will be added: " According to Proxy Mobile IPv6 specification [RFC5213], if the local mobility anchor receives a Proxy Binding Update message from a new mobile access gateway for extending the binding lifetime of the only BCE of this mobile node with the Handoff Indicator value is set to "Inter-MAG Handover - Unknown", the local mobility anchor waits a period of MaxDelayBeforeNewBCEAssign to receive a de-registration message from the previous mobile access gateway before updating the mobile node's BCE with the new point of attachment. Otherwise, the local mobility anchor considers the received Proxy Binding Update message as a request for a new BCE and if processed successfully, the local mobility anchor assigns a different HNP for the new BCE. This document updates the local mobility anchor's behavior in this case. If the local mobility anchor supports the binding revocation mechanism as described in this document, it SHOULD proactively send a Binding Revocation Indication message to the previous mobile access gateway instead of waiting for a de-registration from the previous mobile access gateway. In the Binding Revocation Indication message, the (A) bit MUST be set and the Revocation Trigger MUST be set to "Inter-MAG Handover - Unkown". If the local mobility anchor sent a Binding Revocation Indication message with the Revocation Trigger field set to "Inter-MAG Handover - Unknown" and while waiting for a Binding Revocation Acknowledgement response, the following are possible conditions that the local mobility anchor MUST handle as specified below: o If the local mobility anchor receives a successful Binding Revocation Acknowledgement message or a de-registration message from the previous mobile access gateway, the local mobility anchor MUST update the mobile node BCE in a similar way as if it received a de-registration message as described in [RFC5213]. o If the local mobility anchor receives a Binding Revocation Acknowledgement message with the status field set to "Revocation Failed - MN is Attached", the local mobility anchor SHOULD update the mobile node BCE in a similar way as if it did NOT receive a de-registration before the MaxDelayBeforeNewBCEAssign timer expires by creating a new BCE as described in [RFC5213]. o If the local mobility anchor did not receive a Binding Revocation Acknowledgement message nor a de-registration Proxy Binding Update from the previous mobile access gateway after it exhausted all of the Binding Revocation Indication message retransmissions as described in Section 7.3, the local mobility anchor SHOULD update the mobile node's BCE in a similar way as if it did NOT receive a de-registration before the MaxDelayBeforeNewBCEAssign timer expires by creating a new BCE as described in [RFC5213]. " =20 > -----Original Message----- > From: Julien Laganier [mailto:julien.laganier.ietf@googlemail.com]=20 > Sent: Tuesday, June 02, 2009 6:22 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Vijay Devarapalli; mext > Subject: Re: LMA behavior for HI status unknown (was Re:=20 > Binding Revocation almost ready for IESG) >=20 > Hello Ahmad, >=20 > I think we'd be better with a new revision. >=20 > Thanks. >=20 > --julien >=20 > On Sat, May 23, 2009 at 2:22 PM, Ahmad Muhanna=20 > wrote: > > Hi Vijay, > > > > Regards, > > Ahmad > > > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] > >> Sent: Friday, May 22, 2009 12:56 PM > >> To: Muhanna, Ahmad (RICH1:2H10) > >> Cc: mext; Julien Laganier > >> Subject: LMA behavior for HI status unknown (was Re: Binding=20 > >> Revocation almost ready for IESG) > >> > >> Hi Ahmad, > >> > >> I am going to split the emails into two, since we are dealing with=20 > >> two issues. > >> > >> Ahmad Muhanna wrote: > >> > >> >>>> But what should the MAG behavior be when it receives the > >> following > >> >>>> trigger? > >> >>>> > >> >>>> =A05 =A0Inter-MAG Handover - Unknown > >> >>>> > >> >>> [Ahmad] > >> >>> The MAG will reject the BRI with code "MN still attached" > >> >> :) I mean, > >> >>> the MAG is supposed to check whether the mobile node is > >> attached or > >> >>> not and based on its finding, it should reply back either > >> >> success or > >> >>> failure, e.g., "MN still attached". > >> >> Ok. > >> >> > >> >> So what does the LMA do now? The new MAG is saying the MN > >> attached to > >> >> it and the handoff state is "unknown". The old MAG is > >> saying the MN > >> >> is still attached? Shouldn't this result in a new=20 > mobility session=20 > >> >> being setup for the attachment through the new MAG? It won't be=20 > >> >> treated as a handover anymore. This probably needs to=20 > be explained. > >> >> > >> > [Ahmad] > >> > The LMA does nothing other than what is documented in RFC5213. > >> > This is exactly the same case as if the LMA did not receive a=20 > >> > de-registration from the previous MAG and the timer > >> expired. I do not > >> > think it is necessary to add anything, but we could add=20 > a pointer=20 > >> > to > >> > RFC5213 for this specific case when handling the AD comments. > >> > >> This doesn't make sense. RFC 5213 says if the LMA receives=20 > a PBU with=20 > >> HI set to "handoff state unknown", it should wait for=20 > >> MaxDelayBeforeNewBCEAssign amount of time for a deregistration PBU=20 > >> from the old MAG. If there is no such deregistration=20 > message from the=20 > >> old MAG, it would create a new mobility session. > >> > >> The Binding revocation document suggests that the LMA must send a=20 > >> binding revocation message with the trigger set to "handoff state=20 > >> unknown". If the MN is still attached, the old MAG would=20 > reject the=20 > >> binding revocation. Then the LMA would proceed with creating a new=20 > >> mobility session. > > > > [Ahmad] > > Where in the revocation draft it said that the LMA must send a BRI=20 > > with the trigger set to "handoff state unknown"? > > > >> > >> How can these two be compatible? > >> > > [Ahmad] > > We can debate this offlist, I guess:) > > Please see below. > > > >> IMO, the binding revocation document should say that it is=20 > updating=20 > >> RFC > >> 5213 when it comes to the LMA behavior when it receives a=20 > PBU with HI=20 > >> set to "handoff state unknown". If the LMA and the MAG implement=20 > >> binding revocation, they should follow the mechanism=20 > described in the=20 > >> binding revocation document rather than the one in RFC 5213. > > > > [Ahmad] > > Although, I still believe that these two cases compatible=20 > but I agree=20 > > with the end result that you are proposing. I see your=20 > point when the=20 > > LMA support Binding Revocation and at the same time already support=20 > > RFC5213, we need to be clear on what the LMA needs to do if=20 > it decides=20 > > to send a BRI message to the old MAG rather than waits for a=20 > > de-registration to come. > > > > Will come up with some text which address this option,=20 > i.e., when the=20 > > LMA uses BRI proactively to define if the MN is no longer=20 > attached to=20 > > the old MAG or not to be able to handle the PBU with HI=20 > unknown coming=20 > > from the new MAG. > > > > Do we need a new revision for this or we can add the text=20 > during the=20 > > AD review and comments? > > > >> > >> Vijay > >> > > >=20 From AMUHANNA@nortel.com Wed Jun 10 12:13:39 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2323A6B1D for ; Wed, 10 Jun 2009 12:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.895 X-Spam-Level: X-Spam-Status: No, score=-5.895 tagged_above=-999 required=5 tests=[AWL=0.704, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 kcydVBplFrH6 for ; Wed, 10 Jun 2009 12:13:38 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id D61DE3A6855 for ; Wed, 10 Jun 2009 12:13:37 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5AJCKP25086; Wed, 10 Jun 2009 19:12:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jun 2009 14:13:32 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LMA behavior for HI status unknown (was Re: Binding Revocation almost ready for IESG) Thread-Index: AcnjdFkyQx8CvVS9QxeE9a/DOkS3xwGfAL2gAAOiiFA= From: "Ahmad Muhanna" To: "mext" Cc: Julien Laganier Subject: [MEXT] FW: LMA behavior for HI status unknown (was Re: Binding Revocation almost ready for IESG) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 19:13:39 -0000 =20 Hi All, One minor update. The following sentence to be added as a Note to the = last bullet in order to avoid some implementation to wait so long before = creating a new BCE. " Note that the local mobility anchor SHOULD use the recommended = number of retransmissions for the Binding Revocation Indication message as described in Section 12 to avoid delaying the creation of a new binding cache entry for too long, if the mobile node is actually attaching to the new MAG with a different interface. " The last bullet will read as follows: " o If the local mobility anchor did not receive a Binding Revocation Acknowledgement message nor a de-registration Proxy Binding Update from the previous mobile access gateway after it exhausted all of the Binding Revocation Indication message retransmissions as described in Section 7.3, the local mobility anchor SHOULD update the mobile node's BCE in a similar way as if it did NOT receive a de-registration before the MaxDelayBeforeNewBCEAssign timer expires by creating a new BCE as described in [RFC5213]. Note that the local mobility anchor SHOULD use the recommended number of retransmissions for the Binding Revocation Indication message as described in Section 12 to avoid delaying the creation of a new binding cache entry for too long, if the mobile node is actually attaching to the new MAG with a different interface. " Thanks Vijay! Regards, Ahmad -----Original Message----- From: Muhanna, Ahmad (RICH1:2H10)=20 Sent: Wednesday, June 10, 2009 12:29 PM To: mext Cc: 'Julien Laganier'; Vijay Devarapalli; 'Sri Gundavelli' Subject: RE: LMA behavior for HI status unknown (was Re: Binding = Revocation almost ready for IESG) Hello All, We discussed this offline and we have the following agreed upon text. = Please take a look and let us know if you have any comment, issue or = concern. We are planning for spinning a new revision by the end of the = coming weekend. Many thanks in advance! Ahmad Under section 9.1.1., the following text will be added: " According to Proxy Mobile IPv6 specification [RFC5213], if the local mobility anchor receives a Proxy Binding Update message from a new mobile access gateway for extending the binding lifetime of the only BCE of this mobile node with the Handoff Indicator value is set to "Inter-MAG Handover - Unknown", the local mobility anchor waits a period of MaxDelayBeforeNewBCEAssign to receive a de-registration message from the previous mobile access gateway before updating the mobile node's BCE with the new point of attachment. Otherwise, the local mobility anchor considers the received Proxy Binding Update message as a request for a new BCE and if processed successfully, the local mobility anchor assigns a different HNP for the new BCE. This document updates the local mobility anchor's behavior in this case. If the local mobility anchor supports the binding revocation mechanism as described in this document, it SHOULD proactively send a Binding Revocation Indication message to the previous mobile access gateway instead of waiting for a de-registration from the previous mobile access gateway. In the Binding Revocation Indication message, the (A) bit MUST be set and the Revocation Trigger MUST be set to "Inter-MAG Handover - Unkown". If the local mobility anchor sent a Binding Revocation Indication message with the Revocation Trigger field set to "Inter-MAG Handover - Unknown" and while waiting for a Binding Revocation Acknowledgement response, the following are possible conditions that the local mobility anchor MUST handle as specified below: o If the local mobility anchor receives a successful Binding Revocation Acknowledgement message or a de-registration message from the previous mobile access gateway, the local mobility anchor MUST update the mobile node BCE in a similar way as if it received a de-registration message as described in [RFC5213]. o If the local mobility anchor receives a Binding Revocation Acknowledgement message with the status field set to "Revocation Failed - MN is Attached", the local mobility anchor SHOULD update the mobile node BCE in a similar way as if it did NOT receive a de-registration before the MaxDelayBeforeNewBCEAssign timer expires by creating a new BCE as described in [RFC5213]. o If the local mobility anchor did not receive a Binding Revocation Acknowledgement message nor a de-registration Proxy Binding Update from the previous mobile access gateway after it exhausted all of the Binding Revocation Indication message retransmissions as described in Section 7.3, the local mobility anchor SHOULD update the mobile node's BCE in a similar way as if it did NOT receive a de-registration before the MaxDelayBeforeNewBCEAssign timer expires by creating a new BCE as described in [RFC5213]. " =20 > -----Original Message----- > From: Julien Laganier [mailto:julien.laganier.ietf@googlemail.com] > Sent: Tuesday, June 02, 2009 6:22 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Vijay Devarapalli; mext > Subject: Re: LMA behavior for HI status unknown (was Re:=20 > Binding Revocation almost ready for IESG) >=20 > Hello Ahmad, >=20 > I think we'd be better with a new revision. >=20 > Thanks. >=20 > --julien >=20 > On Sat, May 23, 2009 at 2:22 PM, Ahmad Muhanna =20 > wrote: > > Hi Vijay, > > > > Regards, > > Ahmad > > > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] > >> Sent: Friday, May 22, 2009 12:56 PM > >> To: Muhanna, Ahmad (RICH1:2H10) > >> Cc: mext; Julien Laganier > >> Subject: LMA behavior for HI status unknown (was Re: Binding=20 > >> Revocation almost ready for IESG) > >> > >> Hi Ahmad, > >> > >> I am going to split the emails into two, since we are dealing with=20 > >> two issues. > >> > >> Ahmad Muhanna wrote: > >> > >> >>>> But what should the MAG behavior be when it receives the > >> following > >> >>>> trigger? > >> >>>> > >> >>>> =A05 =A0Inter-MAG Handover - Unknown > >> >>>> > >> >>> [Ahmad] > >> >>> The MAG will reject the BRI with code "MN still attached" > >> >> :) I mean, > >> >>> the MAG is supposed to check whether the mobile node is > >> attached or > >> >>> not and based on its finding, it should reply back either > >> >> success or > >> >>> failure, e.g., "MN still attached". > >> >> Ok. > >> >> > >> >> So what does the LMA do now? The new MAG is saying the MN > >> attached to > >> >> it and the handoff state is "unknown". The old MAG is > >> saying the MN > >> >> is still attached? Shouldn't this result in a new > mobility session > >> >> being setup for the attachment through the new MAG? It won't be=20 > >> >> treated as a handover anymore. This probably needs to > be explained. > >> >> > >> > [Ahmad] > >> > The LMA does nothing other than what is documented in RFC5213. > >> > This is exactly the same case as if the LMA did not receive a=20 > >> > de-registration from the previous MAG and the timer > >> expired. I do not > >> > think it is necessary to add anything, but we could add > a pointer > >> > to > >> > RFC5213 for this specific case when handling the AD comments. > >> > >> This doesn't make sense. RFC 5213 says if the LMA receives > a PBU with > >> HI set to "handoff state unknown", it should wait for=20 > >> MaxDelayBeforeNewBCEAssign amount of time for a deregistration PBU=20 > >> from the old MAG. If there is no such deregistration > message from the > >> old MAG, it would create a new mobility session. > >> > >> The Binding revocation document suggests that the LMA must send a=20 > >> binding revocation message with the trigger set to "handoff state=20 > >> unknown". If the MN is still attached, the old MAG would > reject the > >> binding revocation. Then the LMA would proceed with creating a new=20 > >> mobility session. > > > > [Ahmad] > > Where in the revocation draft it said that the LMA must send a BRI=20 > > with the trigger set to "handoff state unknown"? > > > >> > >> How can these two be compatible? > >> > > [Ahmad] > > We can debate this offlist, I guess:) Please see below. > > > >> IMO, the binding revocation document should say that it is > updating > >> RFC > >> 5213 when it comes to the LMA behavior when it receives a > PBU with HI > >> set to "handoff state unknown". If the LMA and the MAG implement=20 > >> binding revocation, they should follow the mechanism > described in the > >> binding revocation document rather than the one in RFC 5213. > > > > [Ahmad] > > Although, I still believe that these two cases compatible > but I agree > > with the end result that you are proposing. I see your > point when the > > LMA support Binding Revocation and at the same time already support=20 > > RFC5213, we need to be clear on what the LMA needs to do if > it decides > > to send a BRI message to the old MAG rather than waits for a=20 > > de-registration to come. > > > > Will come up with some text which address this option, > i.e., when the > > LMA uses BRI proactively to define if the MN is no longer > attached to > > the old MAG or not to be able to handle the PBU with HI > unknown coming > > from the new MAG. > > > > Do we need a new revision for this or we can add the text > during the > > AD review and comments? > > > >> > >> Vijay > >> > > >=20 From bob@marksmob.com Wed Jun 10 23:11:08 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5E993A68E7 for ; Wed, 10 Jun 2009 23:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 GTLJGKuCbbHP for ; Wed, 10 Jun 2009 23:11:07 -0700 (PDT) Received: from hiltonsmtp.worldspice.net (hiltonsmtp.worldspice.net [216.37.94.58]) by core3.amsl.com (Postfix) with ESMTP id 602AB3A67A7 for ; Wed, 10 Jun 2009 23:11:07 -0700 (PDT) Received: (qmail 14971 invoked by uid 0); 11 Jun 2009 06:11:13 -0000 Received: by simscan 1.4.0 ppid: 14693, pid: 14831, t: 4.7574s scanners: clamav: 0.94.1/m:50/d:9101 spam: 3.2.5 Received: from unknown (HELO RMARKSD6201) (bob@marksmob.com@12.50.84.130) by hiltonsmtp.worldspice.net with ESMTPA; 11 Jun 2009 06:11:08 -0000 Message-ID: From: "Robert Marks" To: "Ahmad Muhanna" , "mext" References: <4A16E743.5010400@wichorus.com><7ad6d6db0906020421m2f6a9cb6xbff75a8da1b43b54@mail.gmail.com> Date: Thu, 11 Jun 2009 01:11:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Julien Laganier Subject: Re: [MEXT] LMA behavior for HI status unknown (was Re: BindingRevocation almost ready for IESG) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 06:11:08 -0000 Hi, When reading the new text for section 9.1.1, I was a little confused by the "Otherwise" beginning the second sentence. Ahmad explained the logic to me, and I think a small change might clarify the intent for other readers. I suggest replacing "Otherwise," with "If a de-registration message is not received," so that the text becomes According to Proxy Mobile IPv6 specification [RFC5213], if the local mobility anchor receives a Proxy Binding Update message from a new mobile access gateway for extending the binding lifetime of the only BCE of this mobile node with the Handoff Indicator value is set to "Inter-MAG Handover - Unknown", the local mobility anchor waits a period of MaxDelayBeforeNewBCEAssign to receive a de-registration message from the previous mobile access gateway before updating the mobile node's BCE with the new point of attachment. If a de-registration message is not received, the local mobility anchor considers the received Proxy Binding Update message as a request for a new BCE and if processed successfully, the local mobility anchor assigns a different HNP for the new BCE. Bob ----- Original Message ----- From: "Ahmad Muhanna" To: "mext" Cc: "Julien Laganier" Sent: Wednesday, June 10, 2009 12:28 PM Subject: Re: [MEXT] LMA behavior for HI status unknown (was Re: BindingRevocation almost ready for IESG) Hello All, We discussed this offline and we have the following agreed upon text. Please take a look and let us know if you have any comment, issue or concern. We are planning for spinning a new revision by the end of the coming weekend. Many thanks in advance! Ahmad Under section 9.1.1., the following text will be added: " According to Proxy Mobile IPv6 specification [RFC5213], if the local mobility anchor receives a Proxy Binding Update message from a new mobile access gateway for extending the binding lifetime of the only BCE of this mobile node with the Handoff Indicator value is set to "Inter-MAG Handover - Unknown", the local mobility anchor waits a period of MaxDelayBeforeNewBCEAssign to receive a de-registration message from the previous mobile access gateway before updating the mobile node's BCE with the new point of attachment. Otherwise, the local mobility anchor considers the received Proxy Binding Update message as a request for a new BCE and if processed successfully, the local mobility anchor assigns a different HNP for the new BCE. This document updates the local mobility anchor's behavior in this case. If the local mobility anchor supports the binding revocation mechanism as described in this document, it SHOULD proactively send a Binding Revocation Indication message to the previous mobile access gateway instead of waiting for a de-registration from the previous mobile access gateway. In the Binding Revocation Indication message, the (A) bit MUST be set and the Revocation Trigger MUST be set to "Inter-MAG Handover - Unkown". If the local mobility anchor sent a Binding Revocation Indication message with the Revocation Trigger field set to "Inter-MAG Handover - Unknown" and while waiting for a Binding Revocation Acknowledgement response, the following are possible conditions that the local mobility anchor MUST handle as specified below: o If the local mobility anchor receives a successful Binding Revocation Acknowledgement message or a de-registration message from the previous mobile access gateway, the local mobility anchor MUST update the mobile node BCE in a similar way as if it received a de-registration message as described in [RFC5213]. o If the local mobility anchor receives a Binding Revocation Acknowledgement message with the status field set to "Revocation Failed - MN is Attached", the local mobility anchor SHOULD update the mobile node BCE in a similar way as if it did NOT receive a de-registration before the MaxDelayBeforeNewBCEAssign timer expires by creating a new BCE as described in [RFC5213]. o If the local mobility anchor did not receive a Binding Revocation Acknowledgement message nor a de-registration Proxy Binding Update from the previous mobile access gateway after it exhausted all of the Binding Revocation Indication message retransmissions as described in Section 7.3, the local mobility anchor SHOULD update the mobile node's BCE in a similar way as if it did NOT receive a de-registration before the MaxDelayBeforeNewBCEAssign timer expires by creating a new BCE as described in [RFC5213]. " > -----Original Message----- > From: Julien Laganier [mailto:julien.laganier.ietf@googlemail.com] > Sent: Tuesday, June 02, 2009 6:22 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Vijay Devarapalli; mext > Subject: Re: LMA behavior for HI status unknown (was Re: > Binding Revocation almost ready for IESG) > > Hello Ahmad, > > I think we'd be better with a new revision. > > Thanks. > > --julien > > On Sat, May 23, 2009 at 2:22 PM, Ahmad Muhanna > wrote: > > Hi Vijay, > > > > Regards, > > Ahmad > > > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] > >> Sent: Friday, May 22, 2009 12:56 PM > >> To: Muhanna, Ahmad (RICH1:2H10) > >> Cc: mext; Julien Laganier > >> Subject: LMA behavior for HI status unknown (was Re: Binding > >> Revocation almost ready for IESG) > >> > >> Hi Ahmad, > >> > >> I am going to split the emails into two, since we are dealing with > >> two issues. > >> > >> Ahmad Muhanna wrote: > >> > >> >>>> But what should the MAG behavior be when it receives the > >> following > >> >>>> trigger? > >> >>>> > >> >>>> 5 Inter-MAG Handover - Unknown > >> >>>> > >> >>> [Ahmad] > >> >>> The MAG will reject the BRI with code "MN still attached" > >> >> :) I mean, > >> >>> the MAG is supposed to check whether the mobile node is > >> attached or > >> >>> not and based on its finding, it should reply back either > >> >> success or > >> >>> failure, e.g., "MN still attached". > >> >> Ok. > >> >> > >> >> So what does the LMA do now? The new MAG is saying the MN > >> attached to > >> >> it and the handoff state is "unknown". The old MAG is > >> saying the MN > >> >> is still attached? Shouldn't this result in a new > mobility session > >> >> being setup for the attachment through the new MAG? It won't be > >> >> treated as a handover anymore. This probably needs to > be explained. > >> >> > >> > [Ahmad] > >> > The LMA does nothing other than what is documented in RFC5213. > >> > This is exactly the same case as if the LMA did not receive a > >> > de-registration from the previous MAG and the timer > >> expired. I do not > >> > think it is necessary to add anything, but we could add > a pointer > >> > to > >> > RFC5213 for this specific case when handling the AD comments. > >> > >> This doesn't make sense. RFC 5213 says if the LMA receives > a PBU with > >> HI set to "handoff state unknown", it should wait for > >> MaxDelayBeforeNewBCEAssign amount of time for a deregistration PBU > >> from the old MAG. If there is no such deregistration > message from the > >> old MAG, it would create a new mobility session. > >> > >> The Binding revocation document suggests that the LMA must send a > >> binding revocation message with the trigger set to "handoff state > >> unknown". If the MN is still attached, the old MAG would > reject the > >> binding revocation. Then the LMA would proceed with creating a new > >> mobility session. > > > > [Ahmad] > > Where in the revocation draft it said that the LMA must send a BRI > > with the trigger set to "handoff state unknown"? > > > >> > >> How can these two be compatible? > >> > > [Ahmad] > > We can debate this offlist, I guess:) > > Please see below. > > > >> IMO, the binding revocation document should say that it is > updating > >> RFC > >> 5213 when it comes to the LMA behavior when it receives a > PBU with HI > >> set to "handoff state unknown". If the LMA and the MAG implement > >> binding revocation, they should follow the mechanism > described in the > >> binding revocation document rather than the one in RFC 5213. > > > > [Ahmad] > > Although, I still believe that these two cases compatible > but I agree > > with the end result that you are proposing. I see your > point when the > > LMA support Binding Revocation and at the same time already support > > RFC5213, we need to be clear on what the LMA needs to do if > it decides > > to send a BRI message to the old MAG rather than waits for a > > de-registration to come. > > > > Will come up with some text which address this option, > i.e., when the > > LMA uses BRI proactively to define if the MN is no longer > attached to > > the old MAG or not to be able to handle the PBU with HI > unknown coming > > from the new MAG. > > > > Do we need a new revision for this or we can add the text > during the > > AD review and comments? > > > >> > >> Vijay > >> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From AMUHANNA@nortel.com Thu Jun 11 00:47:42 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEFA53A6A4A for ; Thu, 11 Jun 2009 00:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.012 X-Spam-Level: X-Spam-Status: No, score=-6.012 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 dVM5AV6FLqiI for ; Thu, 11 Jun 2009 00:47:41 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 1DB363A67A1 for ; Thu, 11 Jun 2009 00:47:40 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5B7kO316939; Thu, 11 Jun 2009 07:46:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Jun 2009 02:47:33 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] LMA behavior for HI status unknown (was Re: BindingRevocation almost ready for IESG) Thread-Index: AcnqW3HYTlrsRdK4RcSajcqJGWt88wADV0Jg References: <4A16E743.5010400@wichorus.com><7ad6d6db0906020421m2f6a9cb6xbff75a8da1b43b54@mail.gmail.com> From: "Ahmad Muhanna" To: "Robert Marks" , "mext" Cc: Julien Laganier Subject: Re: [MEXT] LMA behavior for HI status unknown (was Re: BindingRevocation almost ready for IESG) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 07:47:42 -0000 Hi Bob, Thanks. That looks good. Regards, Ahmad > -----Original Message----- > From: Robert Marks [mailto:bob@marksmob.com]=20 > Sent: Thursday, June 11, 2009 1:11 AM > To: Muhanna, Ahmad (RICH1:2H10); mext > Cc: Julien Laganier > Subject: Re: [MEXT] LMA behavior for HI status unknown (was=20 > Re: BindingRevocation almost ready for IESG) >=20 > Hi, >=20 > When reading the new text for section 9.1.1, I was a little=20 > confused by the "Otherwise" beginning the second sentence.=20 > Ahmad explained the logic to me, and I think a small change=20 > might clarify the intent for other readers. >=20 > I suggest replacing "Otherwise," with "If a de-registration=20 > message is not received," so that the text becomes >=20 > According to Proxy Mobile IPv6 specification [RFC5213], if the local > mobility anchor receives a Proxy Binding Update message from a new > mobile access gateway for extending the binding lifetime of the only > BCE of this mobile node with the Handoff Indicator value is set to > "Inter-MAG Handover - Unknown", the local mobility anchor waits a > period of MaxDelayBeforeNewBCEAssign to receive a de-registration > message from the previous mobile access gateway before updating the > mobile node's BCE with the new point of attachment. If a=20 > de-registration > message is not received, the local mobility anchor=20 > considers the received > Proxy Binding Update message as a request for a new BCE and if > processed successfully, the local mobility anchor assigns a=20 > different HNP > for the new BCE. >=20 > Bob >=20 > ----- Original Message ----- > From: "Ahmad Muhanna" > To: "mext" > Cc: "Julien Laganier" > Sent: Wednesday, June 10, 2009 12:28 PM > Subject: Re: [MEXT] LMA behavior for HI status unknown (was Re:=20 > BindingRevocation almost ready for IESG) >=20 >=20 > Hello All, >=20 > We discussed this offline and we have the following agreed=20 > upon text. Please=20 > take a look and let us know if you have any comment, issue or=20 > concern. We=20 > are planning for spinning a new revision by the end of the=20 > coming weekend. >=20 > Many thanks in advance! > Ahmad >=20 > Under section 9.1.1., the following text will be added: >=20 > " > According to Proxy Mobile IPv6 specification [RFC5213], if=20 > the local > mobility anchor receives a Proxy Binding Update message from a new > mobile access gateway for extending the binding lifetime=20 > of the only > BCE of this mobile node with the Handoff Indicator value is set to > "Inter-MAG Handover - Unknown", the local mobility anchor waits a > period of MaxDelayBeforeNewBCEAssign to receive a de-registration > message from the previous mobile access gateway before updating the > mobile node's BCE with the new point of attachment. Otherwise, the > local mobility anchor considers the received Proxy Binding Update > message as a request for a new BCE and if processed=20 > successfully, the > local mobility anchor assigns a different HNP for the new BCE. >=20 >=20 > This document updates the local mobility anchor's behavior in this > case. If the local mobility anchor supports the binding revocation > mechanism as described in this document, it SHOULD=20 > proactively send a > Binding Revocation Indication message to the previous mobile access > gateway instead of waiting for a de-registration from the previous > mobile access gateway. In the Binding Revocation=20 > Indication message, > the (A) bit MUST be set and the Revocation Trigger MUST be set to > "Inter-MAG Handover - Unkown". >=20 > If the local mobility anchor sent a Binding Revocation Indication > message with the Revocation Trigger field set to=20 > "Inter-MAG Handover > - Unknown" and while waiting for a Binding Revocation=20 > Acknowledgement > response, the following are possible conditions that the local > mobility anchor MUST handle as specified below: >=20 > o If the local mobility anchor receives a successful Binding > Revocation Acknowledgement message or a de-registration message > from the previous mobile access gateway, the local=20 > mobility anchor > MUST update the mobile node BCE in a similar way as if=20 > it received > a de-registration message as described in [RFC5213]. >=20 > o If the local mobility anchor receives a Binding Revocation > Acknowledgement message with the status field set to "Revocation > Failed - MN is Attached", the local mobility anchor SHOULD > update the mobile node BCE in a similar way as if it did NOT > receive a de-registration before the MaxDelayBeforeNewBCEAssign > timer expires by creating a new BCE as described in [RFC5213]. >=20 > o If the local mobility anchor did not receive a Binding=20 > Revocation > Acknowledgement message nor a de-registration Proxy=20 > Binding Update > from the previous mobile access gateway after it=20 > exhausted all of > the Binding Revocation Indication message retransmissions as > described in Section 7.3, the local mobility anchor SHOULD > update the mobile node's BCE in a similar way as if it did NOT > receive a de-registration before the MaxDelayBeforeNewBCEAssign > timer expires by creating a new BCE as described in [RFC5213]. > " >=20 >=20 > > -----Original Message----- > > From: Julien Laganier [mailto:julien.laganier.ietf@googlemail.com] > > Sent: Tuesday, June 02, 2009 6:22 AM > > To: Muhanna, Ahmad (RICH1:2H10) > > Cc: Vijay Devarapalli; mext > > Subject: Re: LMA behavior for HI status unknown (was Re: > > Binding Revocation almost ready for IESG) > > > > Hello Ahmad, > > > > I think we'd be better with a new revision. > > > > Thanks. > > > > --julien > > > > On Sat, May 23, 2009 at 2:22 PM, Ahmad Muhanna > > wrote: > > > Hi Vijay, > > > > > > Regards, > > > Ahmad > > > > > >> -----Original Message----- > > >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] > > >> Sent: Friday, May 22, 2009 12:56 PM > > >> To: Muhanna, Ahmad (RICH1:2H10) > > >> Cc: mext; Julien Laganier > > >> Subject: LMA behavior for HI status unknown (was Re: Binding > > >> Revocation almost ready for IESG) > > >> > > >> Hi Ahmad, > > >> > > >> I am going to split the emails into two, since we are=20 > dealing with > > >> two issues. > > >> > > >> Ahmad Muhanna wrote: > > >> > > >> >>>> But what should the MAG behavior be when it receives the > > >> following > > >> >>>> trigger? > > >> >>>> > > >> >>>> 5 Inter-MAG Handover - Unknown > > >> >>>> > > >> >>> [Ahmad] > > >> >>> The MAG will reject the BRI with code "MN still attached" > > >> >> :) I mean, > > >> >>> the MAG is supposed to check whether the mobile node is > > >> attached or > > >> >>> not and based on its finding, it should reply back either > > >> >> success or > > >> >>> failure, e.g., "MN still attached". > > >> >> Ok. > > >> >> > > >> >> So what does the LMA do now? The new MAG is saying the MN > > >> attached to > > >> >> it and the handoff state is "unknown". The old MAG is > > >> saying the MN > > >> >> is still attached? Shouldn't this result in a new > > mobility session > > >> >> being setup for the attachment through the new MAG?=20 > It won't be > > >> >> treated as a handover anymore. This probably needs to > > be explained. > > >> >> > > >> > [Ahmad] > > >> > The LMA does nothing other than what is documented in RFC5213. > > >> > This is exactly the same case as if the LMA did not receive a > > >> > de-registration from the previous MAG and the timer > > >> expired. I do not > > >> > think it is necessary to add anything, but we could add > > a pointer > > >> > to > > >> > RFC5213 for this specific case when handling the AD comments. > > >> > > >> This doesn't make sense. RFC 5213 says if the LMA receives > > a PBU with > > >> HI set to "handoff state unknown", it should wait for > > >> MaxDelayBeforeNewBCEAssign amount of time for a=20 > deregistration PBU > > >> from the old MAG. If there is no such deregistration > > message from the > > >> old MAG, it would create a new mobility session. > > >> > > >> The Binding revocation document suggests that the LMA must send a > > >> binding revocation message with the trigger set to "handoff state > > >> unknown". If the MN is still attached, the old MAG would > > reject the > > >> binding revocation. Then the LMA would proceed with=20 > creating a new > > >> mobility session. > > > > > > [Ahmad] > > > Where in the revocation draft it said that the LMA must send a BRI > > > with the trigger set to "handoff state unknown"? > > > > > >> > > >> How can these two be compatible? > > >> > > > [Ahmad] > > > We can debate this offlist, I guess:) > > > Please see below. > > > > > >> IMO, the binding revocation document should say that it is > > updating > > >> RFC > > >> 5213 when it comes to the LMA behavior when it receives a > > PBU with HI > > >> set to "handoff state unknown". If the LMA and the MAG implement > > >> binding revocation, they should follow the mechanism > > described in the > > >> binding revocation document rather than the one in RFC 5213. > > > > > > [Ahmad] > > > Although, I still believe that these two cases compatible > > but I agree > > > with the end result that you are proposing. I see your > > point when the > > > LMA support Binding Revocation and at the same time=20 > already support > > > RFC5213, we need to be clear on what the LMA needs to do if > > it decides > > > to send a BRI message to the old MAG rather than waits for a > > > de-registration to come. > > > > > > Will come up with some text which address this option, > > i.e., when the > > > LMA uses BRI proactively to define if the MN is no longer > > attached to > > > the old MAG or not to be able to handle the PBU with HI > > unknown coming > > > from the new MAG. > > > > > > Do we need a new revision for this or we can add the text > > during the > > > AD review and comments? > > > > > >> > > >> Vijay > > >> > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 >=20 >=20 >=20 From root@core3.amsl.com Sun Jun 14 07:30:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EA1603A6977; Sun, 14 Jun 2009 07:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090614143001.EA1603A6977@core3.amsl.com> Date: Sun, 14 Jun 2009 07:30:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 14:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-ietf-mext-binding-revocation-07.txt Pages : 39 Date : 2009-06-14 This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-binding-revocation-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-14072828.I-D@ietf.org> --NextPart-- From AMUHANNA@nortel.com Sun Jun 14 07:34:35 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC4613A6803 for ; Sun, 14 Jun 2009 07:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.555 X-Spam-Level: X-Spam-Status: No, score=-5.555 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083] 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 PR6K4HQNyFsA for ; Sun, 14 Jun 2009 07:34:34 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id F1C053A69B7 for ; Sun, 14 Jun 2009 07:34:33 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5EEXIc08969; Sun, 14 Jun 2009 14:33:18 GMT Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 14 Jun 2009 09:34:32 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LMA behavior for HI status unknown (was Re: Binding Revocation almost ready for IESG) thread-index: AcnjdFkyQx8CvVS9QxeE9a/DOkS3xwGfAL2gAAOiiFAAv4A6EA== From: "Ahmad Muhanna" To: "mext" Cc: Julien Laganier Subject: Re: [MEXT] LMA behavior for HI status unknown (was Re: Binding Revocation almost ready for IESG) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 14:34:35 -0000 Hi Julien and All, A new revision (07) has been submitted with this change only. Please let me know if you have any comments. Regards, Ahmad ++++ A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Mobility EXTensions for IPv6 Working = Group of the IETF. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-ietf-mext-binding-revocation-07.txt Pages : 39 Date : 2009-06-14 This document defines a binding revocation mechanism to terminate a = mobile node's mobility session and the associated resources. These = semantics are generic enough and can be used by mobility entities in the = case of Mobile IPv6 and its extensions. This mechanism allows the = mobility entity which initiates the revocation procedure to request its = corresponding one to terminate either one, multiple or all specified = binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-07= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader = implementation to automatically retrieve the ASCII version of the = Internet-Draft. =20 > -----Original Message----- > From: Muhanna, Ahmad (RICH1:2H10)=20 > Sent: Wednesday, June 10, 2009 2:14 PM > To: mext > Cc: 'Julien Laganier'; 'Vijay Devarapalli'; 'Sri Gundavelli' > Subject: FW: LMA behavior for HI status unknown (was Re:=20 > Binding Revocation almost ready for IESG) >=20 > =20 > Hi All, > One minor update. The following sentence to be added as a=20 > Note to the last bullet in order to avoid some implementation=20 > to wait so long before creating a new BCE. >=20 >=20 > " > Note that the local mobility anchor SHOULD use the=20 > recommended number > of retransmissions for the Binding Revocation Indication message > as described in Section 12 to avoid delaying the=20 > creation of a new > binding cache entry for too long, if the mobile node is actually > attaching to the new MAG with a different interface. > " >=20 > The last bullet will read as follows: >=20 > " > o If the local mobility anchor did not receive a Binding=20 > Revocation > Acknowledgement message nor a de-registration Proxy=20 > Binding Update > from the previous mobile access gateway after it=20 > exhausted all of > the Binding Revocation Indication message retransmissions as > described in Section 7.3, the local mobility anchor=20 > SHOULD update > the mobile node's BCE in a similar way as if it did NOT=20 > receive a > de-registration before the MaxDelayBeforeNewBCEAssign timer > expires by creating a new BCE as described in [RFC5213]. Note > that the local mobility anchor SHOULD use the recommended number > of retransmissions for the Binding Revocation Indication message > as described in Section 12 to avoid delaying the=20 > creation of a new > binding cache entry for too long, if the mobile node is actually > attaching to the new MAG with a different interface. > " >=20 > Thanks Vijay! >=20 > Regards, > Ahmad >=20 > -----Original Message----- > From: Muhanna, Ahmad (RICH1:2H10) > Sent: Wednesday, June 10, 2009 12:29 PM > To: mext > Cc: 'Julien Laganier'; Vijay Devarapalli; 'Sri Gundavelli' > Subject: RE: LMA behavior for HI status unknown (was Re:=20 > Binding Revocation almost ready for IESG) >=20 > Hello All, >=20 > We discussed this offline and we have the following agreed=20 > upon text. Please take a look and let us know if you have any=20 > comment, issue or concern. We are planning for spinning a new=20 > revision by the end of the coming weekend. >=20 > Many thanks in advance! > Ahmad >=20 > Under section 9.1.1., the following text will be added: >=20 > " > According to Proxy Mobile IPv6 specification [RFC5213], if=20 > the local > mobility anchor receives a Proxy Binding Update message from a new > mobile access gateway for extending the binding lifetime=20 > of the only > BCE of this mobile node with the Handoff Indicator value is set to > "Inter-MAG Handover - Unknown", the local mobility anchor waits a > period of MaxDelayBeforeNewBCEAssign to receive a de-registration > message from the previous mobile access gateway before updating the > mobile node's BCE with the new point of attachment. Otherwise, the > local mobility anchor considers the received Proxy Binding Update > message as a request for a new BCE and if processed=20 > successfully, the > local mobility anchor assigns a different HNP for the new BCE. >=20 >=20 > This document updates the local mobility anchor's behavior in this > case. If the local mobility anchor supports the binding revocation > mechanism as described in this document, it SHOULD=20 > proactively send a > Binding Revocation Indication message to the previous mobile access > gateway instead of waiting for a de-registration from the previous > mobile access gateway. In the Binding Revocation=20 > Indication message, > the (A) bit MUST be set and the Revocation Trigger MUST be set to > "Inter-MAG Handover - Unkown". >=20 > If the local mobility anchor sent a Binding Revocation Indication > message with the Revocation Trigger field set to=20 > "Inter-MAG Handover > - Unknown" and while waiting for a Binding Revocation=20 > Acknowledgement > response, the following are possible conditions that the local > mobility anchor MUST handle as specified below: >=20 > o If the local mobility anchor receives a successful Binding > Revocation Acknowledgement message or a de-registration message > from the previous mobile access gateway, the local=20 > mobility anchor > MUST update the mobile node BCE in a similar way as if=20 > it received > a de-registration message as described in [RFC5213]. >=20 > o If the local mobility anchor receives a Binding Revocation > Acknowledgement message with the status field set to "Revocation > Failed - MN is Attached", the local mobility anchor SHOULD > update the mobile node BCE in a similar way as if it did NOT > receive a de-registration before the MaxDelayBeforeNewBCEAssign > timer expires by creating a new BCE as described in [RFC5213]. >=20 > o If the local mobility anchor did not receive a Binding=20 > Revocation > Acknowledgement message nor a de-registration Proxy=20 > Binding Update > from the previous mobile access gateway after it=20 > exhausted all of > the Binding Revocation Indication message retransmissions as > described in Section 7.3, the local mobility anchor SHOULD > update the mobile node's BCE in a similar way as if it did NOT > receive a de-registration before the MaxDelayBeforeNewBCEAssign > timer expires by creating a new BCE as described in [RFC5213]. > " > =20 >=20 > > -----Original Message----- > > From: Julien Laganier [mailto:julien.laganier.ietf@googlemail.com] > > Sent: Tuesday, June 02, 2009 6:22 AM > > To: Muhanna, Ahmad (RICH1:2H10) > > Cc: Vijay Devarapalli; mext > > Subject: Re: LMA behavior for HI status unknown (was Re:=20 > > Binding Revocation almost ready for IESG) > >=20 > > Hello Ahmad, > >=20 > > I think we'd be better with a new revision. > >=20 > > Thanks. > >=20 > > --julien > >=20 > > On Sat, May 23, 2009 at 2:22 PM, Ahmad Muhanna > > wrote: > > > Hi Vijay, > > > > > > Regards, > > > Ahmad > > > > > >> -----Original Message----- > > >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] > > >> Sent: Friday, May 22, 2009 12:56 PM > > >> To: Muhanna, Ahmad (RICH1:2H10) > > >> Cc: mext; Julien Laganier > > >> Subject: LMA behavior for HI status unknown (was Re: Binding=20 > > >> Revocation almost ready for IESG) > > >> > > >> Hi Ahmad, > > >> > > >> I am going to split the emails into two, since we are=20 > dealing with=20 > > >> two issues. > > >> > > >> Ahmad Muhanna wrote: > > >> > > >> >>>> But what should the MAG behavior be when it receives the > > >> following > > >> >>>> trigger? > > >> >>>> > > >> >>>> =A05 =A0Inter-MAG Handover - Unknown > > >> >>>> > > >> >>> [Ahmad] > > >> >>> The MAG will reject the BRI with code "MN still attached" > > >> >> :) I mean, > > >> >>> the MAG is supposed to check whether the mobile node is > > >> attached or > > >> >>> not and based on its finding, it should reply back either > > >> >> success or > > >> >>> failure, e.g., "MN still attached". > > >> >> Ok. > > >> >> > > >> >> So what does the LMA do now? The new MAG is saying the MN > > >> attached to > > >> >> it and the handoff state is "unknown". The old MAG is > > >> saying the MN > > >> >> is still attached? Shouldn't this result in a new > > mobility session > > >> >> being setup for the attachment through the new MAG?=20 > It won't be=20 > > >> >> treated as a handover anymore. This probably needs to > > be explained. > > >> >> > > >> > [Ahmad] > > >> > The LMA does nothing other than what is documented in RFC5213. > > >> > This is exactly the same case as if the LMA did not receive a=20 > > >> > de-registration from the previous MAG and the timer > > >> expired. I do not > > >> > think it is necessary to add anything, but we could add > > a pointer > > >> > to > > >> > RFC5213 for this specific case when handling the AD comments. > > >> > > >> This doesn't make sense. RFC 5213 says if the LMA receives > > a PBU with > > >> HI set to "handoff state unknown", it should wait for=20 > > >> MaxDelayBeforeNewBCEAssign amount of time for a=20 > deregistration PBU=20 > > >> from the old MAG. If there is no such deregistration > > message from the > > >> old MAG, it would create a new mobility session. > > >> > > >> The Binding revocation document suggests that the LMA=20 > must send a=20 > > >> binding revocation message with the trigger set to=20 > "handoff state=20 > > >> unknown". If the MN is still attached, the old MAG would > > reject the > > >> binding revocation. Then the LMA would proceed with=20 > creating a new=20 > > >> mobility session. > > > > > > [Ahmad] > > > Where in the revocation draft it said that the LMA must=20 > send a BRI=20 > > > with the trigger set to "handoff state unknown"? > > > > > >> > > >> How can these two be compatible? > > >> > > > [Ahmad] > > > We can debate this offlist, I guess:) Please see below. > > > > > >> IMO, the binding revocation document should say that it is > > updating > > >> RFC > > >> 5213 when it comes to the LMA behavior when it receives a > > PBU with HI > > >> set to "handoff state unknown". If the LMA and the MAG implement=20 > > >> binding revocation, they should follow the mechanism > > described in the > > >> binding revocation document rather than the one in RFC 5213. > > > > > > [Ahmad] > > > Although, I still believe that these two cases compatible > > but I agree > > > with the end result that you are proposing. I see your > > point when the > > > LMA support Binding Revocation and at the same time=20 > already support=20 > > > RFC5213, we need to be clear on what the LMA needs to do if > > it decides > > > to send a BRI message to the old MAG rather than waits for a=20 > > > de-registration to come. > > > > > > Will come up with some text which address this option, > > i.e., when the > > > LMA uses BRI proactively to define if the MN is no longer > > attached to > > > the old MAG or not to be able to handle the PBU with HI > > unknown coming > > > from the new MAG. > > > > > > Do we need a new revision for this or we can add the text > > during the > > > AD review and comments? > > > > > >> > > >> Vijay > > >> > > > > >=20 From julien.laganier.ietf@googlemail.com Mon Jun 15 03:43:09 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 038CF3A67AE for ; Mon, 15 Jun 2009 03:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 WFWnvKpQ2KVv for ; Mon, 15 Jun 2009 03:43:07 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id D44883A6A86 for ; Mon, 15 Jun 2009 03:43:06 -0700 (PDT) Received: by bwz9 with SMTP id 9so3223379bwz.37 for ; Mon, 15 Jun 2009 03:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=e0udH8oCJLa39U9yE5eC/wvWM3bN6anQR8m6n77KJV4=; b=SYg5ZxwfbyEsUZWtcDkr7SKevl6wNe5swrzy1Zn0s96HVv8IKOBmurV2C1C/y3tWyn SF8i+x3IzYhmV9p/NrilFI/zFa/zRIe6cVV6Yc0hLTyjktMoWklYa/8nvabCUZ59Knui Jr4RpF7vs7fO31QmKI/s7OTMCDNxnN9Pbqmcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GZH8GcMlTCXtQCSITYFWaluP50FYAANgaKX6BZOe6kxQwM7WIqNL0JH3vhnu54Ny/Z VRtSZtBcg3FyXV0ZSfaWJfpeFizRi9glMvCz4PESIxi4EPYy/IjsezbU7BPcXQLwGLkI karFEaK0FGDtxfwLjnDkQk1UQt+tjKEUwk68A= MIME-Version: 1.0 Received: by 10.204.52.146 with SMTP id i18mr6902766bkg.82.1245062570598; Mon, 15 Jun 2009 03:42:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jun 2009 12:42:50 +0200 Message-ID: <7ad6d6db0906150342n18ad0f90kdf57a6ff2bcaac62@mail.gmail.com> From: Julien Laganier To: Ahmad Muhanna Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] LMA behavior for HI status unknown (was Re: Binding Revocation almost ready for IESG) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 10:43:09 -0000 Folks, You have 'til the end of the week to comment on the last version of the draft after which we consider it is ready and will forward it to IESG to request publication as RFC. --julien & marcelo, MEXT chairs On Sun, Jun 14, 2009 at 4:34 PM, Ahmad Muhanna wrote: > Hi Julien and All, > > A new revision (07) has been submitted with this change only. > Please let me know if you have any comments. > > Regards, > Ahmad > > ++++ > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Mobility EXTensions for IPv6 Working Gro= up of the IETF. > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Binding Revocation for IPv6 Mo= bility > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : A. Muhanna, et al. > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-mext-binding-revocati= on-07.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 39 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-06-14 > > This document defines a binding revocation mechanism to terminate a mobil= e node's mobility session and the associated resources. =A0These semantics = are generic enough and can be used by mobility entities in the case of Mobi= le IPv6 and its extensions. =A0This mechanism allows the mobility entity wh= ich initiates the revocation procedure to request its corresponding one to = terminate either one, multiple or all specified binding cache entries. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-07= .txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader implemen= tation to automatically retrieve the ASCII version of the Internet-Draft. > > >> -----Original Message----- >> From: Muhanna, Ahmad (RICH1:2H10) >> Sent: Wednesday, June 10, 2009 2:14 PM >> To: mext >> Cc: 'Julien Laganier'; 'Vijay Devarapalli'; 'Sri Gundavelli' >> Subject: FW: LMA behavior for HI status unknown (was Re: >> Binding Revocation almost ready for IESG) >> >> >> Hi All, >> One minor update. The following sentence to be added as a >> Note to the last bullet in order to avoid some implementation >> to wait so long before creating a new BCE. >> >> >> " >> =A0 =A0 =A0 Note that the local mobility anchor SHOULD use the >> recommended number >> =A0 =A0 =A0 of retransmissions for the Binding Revocation Indication mes= sage >> =A0 =A0 =A0 as described in Section 12 to avoid delaying the >> creation of a new >> =A0 =A0 =A0 binding cache entry for too long, if the mobile node is actu= ally >> =A0 =A0 =A0 attaching to the new MAG with a different interface. >> " >> >> The last bullet will read as follows: >> >> " >> =A0 =A0o =A0If the local mobility anchor did not receive a Binding >> Revocation >> =A0 =A0 =A0 Acknowledgement message nor a de-registration Proxy >> Binding Update >> =A0 =A0 =A0 from the previous mobile access gateway after it >> exhausted all of >> =A0 =A0 =A0 the Binding Revocation Indication message retransmissions as >> =A0 =A0 =A0 described in Section 7.3, the local mobility anchor >> SHOULD update >> =A0 =A0 =A0 the mobile node's BCE in a similar way as if it did NOT >> receive a >> =A0 =A0 =A0 de-registration before the MaxDelayBeforeNewBCEAssign timer >> =A0 =A0 =A0 expires by creating a new BCE as described in [RFC5213]. =A0= Note >> =A0 =A0 =A0 that the local mobility anchor SHOULD use the recommended nu= mber >> =A0 =A0 =A0 of retransmissions for the Binding Revocation Indication mes= sage >> =A0 =A0 =A0 as described in Section 12 to avoid delaying the >> creation of a new >> =A0 =A0 =A0 binding cache entry for too long, if the mobile node is actu= ally >> =A0 =A0 =A0 attaching to the new MAG with a different interface. >> " >> >> Thanks Vijay! >> >> Regards, >> Ahmad >> >> -----Original Message----- >> From: Muhanna, Ahmad (RICH1:2H10) >> Sent: Wednesday, June 10, 2009 12:29 PM >> To: mext >> Cc: 'Julien Laganier'; Vijay Devarapalli; 'Sri Gundavelli' >> Subject: RE: LMA behavior for HI status unknown (was Re: >> Binding Revocation almost ready for IESG) >> >> Hello All, >> >> We discussed this offline and we have the following agreed >> upon text. Please take a look and let us know if you have any >> comment, issue or concern. We are planning for spinning a new >> revision by the end of the coming weekend. >> >> Many thanks in advance! >> Ahmad >> >> Under section 9.1.1., the following text will be added: >> >> " >> =A0 =A0According to Proxy Mobile IPv6 specification [RFC5213], if >> the local >> =A0 =A0mobility anchor receives a Proxy Binding Update message from a ne= w >> =A0 =A0mobile access gateway for extending the binding lifetime >> of the only >> =A0 =A0BCE of this mobile node with the Handoff Indicator value is set t= o >> =A0 =A0"Inter-MAG Handover - Unknown", the local mobility anchor waits a >> =A0 =A0period of MaxDelayBeforeNewBCEAssign to receive a de-registration >> =A0 =A0message from the previous mobile access gateway before updating t= he >> =A0 =A0mobile node's BCE with the new point of attachment. =A0Otherwise,= the >> =A0 =A0local mobility anchor considers the received Proxy Binding Update >> =A0 =A0message as a request for a new BCE and if processed >> successfully, the >> =A0 =A0local mobility anchor assigns a different HNP for the new BCE. >> >> >> =A0 =A0This document updates the local mobility anchor's behavior in thi= s >> =A0 =A0case. =A0If the local mobility anchor supports the binding revoca= tion >> =A0 =A0mechanism as described in this document, it SHOULD >> proactively send a >> =A0 =A0Binding Revocation Indication message to the previous mobile acce= ss >> =A0 =A0gateway instead of waiting for a de-registration from the previou= s >> =A0 =A0mobile access gateway. =A0In the Binding Revocation >> Indication message, >> =A0 =A0the (A) bit MUST be set and the Revocation Trigger MUST be set to >> =A0 =A0"Inter-MAG Handover - Unkown". >> >> =A0 =A0If the local mobility anchor sent a Binding Revocation Indication >> =A0 =A0message with the Revocation Trigger field set to >> "Inter-MAG Handover >> =A0 =A0- Unknown" and while waiting for a Binding Revocation >> Acknowledgement >> =A0 =A0response, the following are possible conditions that the local >> =A0 =A0mobility anchor MUST handle as specified below: >> >> =A0 =A0o =A0If the local mobility anchor receives a successful Binding >> =A0 =A0 =A0 Revocation Acknowledgement message or a de-registration mess= age >> =A0 =A0 =A0 from the previous mobile access gateway, the local >> mobility anchor >> =A0 =A0 =A0 MUST update the mobile node BCE in a similar way as if >> it received >> =A0 =A0 =A0 a de-registration message as described in [RFC5213]. >> >> =A0 =A0o =A0If the local mobility anchor receives a Binding Revocation >> =A0 =A0 =A0 Acknowledgement message with the status field set to "Revoca= tion >> =A0 =A0 =A0 Failed - MN is Attached", the local mobility anchor SHOULD >> =A0 =A0 =A0 update the mobile node BCE in a similar way as if it did NOT >> =A0 =A0 =A0 receive a de-registration before the MaxDelayBeforeNewBCEAss= ign >> =A0 =A0 =A0 timer expires by creating a new BCE as described in [RFC5213= ]. >> >> =A0 =A0o =A0If the local mobility anchor did not receive a Binding >> Revocation >> =A0 =A0 =A0 Acknowledgement message nor a de-registration Proxy >> Binding Update >> =A0 =A0 =A0 from the previous mobile access gateway after it >> exhausted all of >> =A0 =A0 =A0 the Binding Revocation Indication message retransmissions as >> =A0 =A0 =A0 described in Section 7.3, the local mobility anchor SHOULD >> =A0 =A0 =A0 update the mobile node's BCE in a similar way as if it did N= OT >> =A0 =A0 =A0 receive a de-registration before the MaxDelayBeforeNewBCEAss= ign >> =A0 =A0 =A0 timer expires by creating a new BCE as described in [RFC5213= ]. >> " >> >> >> > -----Original Message----- >> > From: Julien Laganier [mailto:julien.laganier.ietf@googlemail.com] >> > Sent: Tuesday, June 02, 2009 6:22 AM >> > To: Muhanna, Ahmad (RICH1:2H10) >> > Cc: Vijay Devarapalli; mext >> > Subject: Re: LMA behavior for HI status unknown (was Re: >> > Binding Revocation almost ready for IESG) >> > >> > Hello Ahmad, >> > >> > I think we'd be better with a new revision. >> > >> > Thanks. >> > >> > --julien >> > >> > On Sat, May 23, 2009 at 2:22 PM, Ahmad Muhanna >> > wrote: >> > > Hi Vijay, >> > > >> > > Regards, >> > > Ahmad >> > > >> > >> -----Original Message----- >> > >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >> > >> Sent: Friday, May 22, 2009 12:56 PM >> > >> To: Muhanna, Ahmad (RICH1:2H10) >> > >> Cc: mext; Julien Laganier >> > >> Subject: LMA behavior for HI status unknown (was Re: Binding >> > >> Revocation almost ready for IESG) >> > >> >> > >> Hi Ahmad, >> > >> >> > >> I am going to split the emails into two, since we are >> dealing with >> > >> two issues. >> > >> >> > >> Ahmad Muhanna wrote: >> > >> >> > >> >>>> But what should the MAG behavior be when it receives the >> > >> following >> > >> >>>> trigger? >> > >> >>>> >> > >> >>>> =A05 =A0Inter-MAG Handover - Unknown >> > >> >>>> >> > >> >>> [Ahmad] >> > >> >>> The MAG will reject the BRI with code "MN still attached" >> > >> >> :) I mean, >> > >> >>> the MAG is supposed to check whether the mobile node is >> > >> attached or >> > >> >>> not and based on its finding, it should reply back either >> > >> >> success or >> > >> >>> failure, e.g., "MN still attached". >> > >> >> Ok. >> > >> >> >> > >> >> So what does the LMA do now? The new MAG is saying the MN >> > >> attached to >> > >> >> it and the handoff state is "unknown". The old MAG is >> > >> saying the MN >> > >> >> is still attached? Shouldn't this result in a new >> > mobility session >> > >> >> being setup for the attachment through the new MAG? >> It won't be >> > >> >> treated as a handover anymore. This probably needs to >> > be explained. >> > >> >> >> > >> > [Ahmad] >> > >> > The LMA does nothing other than what is documented in RFC5213. >> > >> > This is exactly the same case as if the LMA did not receive a >> > >> > de-registration from the previous MAG and the timer >> > >> expired. I do not >> > >> > think it is necessary to add anything, but we could add >> > a pointer >> > >> > to >> > >> > RFC5213 for this specific case when handling the AD comments. >> > >> >> > >> This doesn't make sense. RFC 5213 says if the LMA receives >> > a PBU with >> > >> HI set to "handoff state unknown", it should wait for >> > >> MaxDelayBeforeNewBCEAssign amount of time for a >> deregistration PBU >> > >> from the old MAG. If there is no such deregistration >> > message from the >> > >> old MAG, it would create a new mobility session. >> > >> >> > >> The Binding revocation document suggests that the LMA >> must send a >> > >> binding revocation message with the trigger set to >> "handoff state >> > >> unknown". If the MN is still attached, the old MAG would >> > reject the >> > >> binding revocation. Then the LMA would proceed with >> creating a new >> > >> mobility session. >> > > >> > > [Ahmad] >> > > Where in the revocation draft it said that the LMA must >> send a BRI >> > > with the trigger set to "handoff state unknown"? >> > > >> > >> >> > >> How can these two be compatible? >> > >> >> > > [Ahmad] >> > > We can debate this offlist, I guess:) Please see below. >> > > >> > >> IMO, the binding revocation document should say that it is >> > updating >> > >> RFC >> > >> 5213 when it comes to the LMA behavior when it receives a >> > PBU with HI >> > >> set to "handoff state unknown". If the LMA and the MAG implement >> > >> binding revocation, they should follow the mechanism >> > described in the >> > >> binding revocation document rather than the one in RFC 5213. >> > > >> > > [Ahmad] >> > > Although, I still believe that these two cases compatible >> > but I agree >> > > with the end result that you are proposing. I see your >> > point when the >> > > LMA support Binding Revocation and at the same time >> already support >> > > RFC5213, we need to be clear on what the LMA needs to do if >> > it decides >> > > to send a BRI message to the old MAG rather than waits for a >> > > de-registration to come. >> > > >> > > Will come up with some text which address this option, >> > i.e., when the >> > > LMA uses BRI proactively to define if the MN is no longer >> > attached to >> > > the old MAG or not to be able to handle the PBU with HI >> > unknown coming >> > > from the new MAG. >> > > >> > > Do we need a new revision for this or we can add the text >> > during the >> > > AD review and comments? >> > > >> > >> >> > >> Vijay >> > >> >> > > >> > > From jari.arkko@piuha.net Tue Jun 16 14:12:19 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF423A6D71 for ; Tue, 16 Jun 2009 14:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 mNqkQ9rP9rLQ for ; Tue, 16 Jun 2009 14:12:18 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id E9E233A6BF0 for ; Tue, 16 Jun 2009 14:12:14 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 0F4F2198787; Wed, 17 Jun 2009 00:12:24 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 0CA84198671; Wed, 17 Jun 2009 00:12:22 +0300 (EEST) Message-ID: <4A380AB6.2080407@piuha.net> Date: Tue, 16 Jun 2009 17:12:22 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: draft-ietf-mext-aero-reqs@tools.ietf.org, "mext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [MEXT] AD review of draft-ietf-mext-aero-reqs X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 21:12:19 -0000 I have reviewed this draft. The document is generally well written and it was easy to read. There were no major problems, but there are a number of issues that I think warrant producing a new version. Here are my comments: Substantial comments: > This version has been reviewed by members of the International Civil > Aviation Orgnanization (ICAO) and other aeronautical communications > standards bodies, and contributed to by a number of aeronautical > communications experts outside the normal IETF process. > What kind of review was actually performed? The above text sounds like a formal review and acceptance was given. If something more informal was actually done, please change the text accordingly. Also, "this version" may not be appropriate as we intend to publish this as an RFC. Maybe "Input to these requirements was given by aeronautical communications experts outside the IETF, including members of the ...". > A need for high availability of connectivity to ground networks > arises from the use of IP networking for carrying safety-of-life > critical traffic. For this reason, single points of failure need to > be avoided. If an RO solution assumes either a single MR onboard, a > single HA, or some similar vulnerable point, and is not usable when > the network includes standard reliability mechanisms for routers, > then the RO technique will not be acceptable. An RO solution also > MUST NOT itself imply a single point of failure. Hmm. There's a hidden requirement here that you actually cannot cope with the basic NEMO at all (even without RO), because Mobile IP is by its nature relies on a single point of failure (the HA). You _also_ need another type of an extension to support multiple HAs for the same home address. You should explicitly indicate that such a hidden requirement exists and that its outside the scope of the RO work. Its good that the end of 3.4.1 already says that Internet-less operation is ruled out, and that HA/MR redundancy mechanisms are ruled out. But it would be good to add the explicit note about this. Or are you thinking of using the RO solution as a way around this requirement? To some small extent this would be possible. E.g., prefix certificates could indicate to CRs that you can claim yourself as the destination for a particular prefix. This would enable applications to work. However, it would not enable a CN in some random location to send a packet to the aircraft, unless the aircraft's MR had already established RO with a router near the CN. > The first security requirement is driven by concerns expressed by ATS > communications engineers. The concern is with the air-ground links > to a craft, and their current lack of security. If an RO scheme > exposes the MNP to eavesdroppers on these links, it may enable > attackers to easily send packets towards onboard networks of crafts. > The RO scheme should use some reasonable form of encryption (e.g. > standard ESP transforms) in order to protect any new RO signalling > data that contains the MNP. I think you mean integrity protection or authentication, not encryption. Encryption may not prevent the attacker from falsifying a signaling packet. I would simply say ... reasonable security mechanisms (e.g., strong authentication). Also, I do not think the security of your networks can be based on the MNP being a secret. The text is fuzzy about what the real issues are. Note that I think the requirement from 3.8 was crystal clear. But the 3.8.1 text is making things a little more less clear. I would suggest cutting some of the text. > The second security requirement is driven by the greater risk of > flooding attacks that are started by an attacker redirecting an MNP's > traffic to some target victim CoA. This is somewhat worse than the > case for MIPv6 mobile host RO, because the MNP's traffic is > potentially a higher rate than that of a single mobile host's HoA. > To protect bindings to bogus CoAs from being sent, the RO scheme must > somehow validate that an MR actually possesses any CoAs that it > claims. In typical Mobile IPv6 RO, the return routability test > provides a form of validation, under certain assumptions. For the > purposes of aeronautics, to demonstrate ownership of the CoA, it is > safe to assume ingress filtering on the part of the access network > providers, in conjunction with the ability to correlate a BU's source > address and the decrypted alternate CoA at the end recipient of the > BU. (Note: this is particularly subject to MEXT discussion) Again, the requirement in 3.8 was great. The justifications are less convincing. For instance, its not clear to me at all that a malicious MR will have greater bandwidth than a malicious MN. I would simply say: "The second security requirement is driven by the risk of flooding attacks that are started by an attacker redirecting an MNP's traffic to some target victim CoA. To protect bindings to bogus CoAs from being sent, the RO scheme must somehow validate that an MR actually possesses any CoAs that it claims. For the purposes of aeronautics, it is safe to assume ingress filtering is in place in the access networks." > It is felt by many individuals that by the time the IP-based ATN > grows into production use, there will be a global PKI useable for > ATS, though it is agreed that such a PKI does not currently exist, > and will take time to develop both technically and politically. I think you mean s/global PKI/global ATN-specific PKI/. You should not hold your breath for a global all-purpose PKI. > If the RO solution assumes that some amount > of preconfiguration of flow properties (port number ranges, etc.) is > required, this could make the integration of new applications or > protocols difficult. An RO scheme might assume this in order to > classify between flows that prefer the MRHA tunnel to an optimized > path per requirement Req1, for instance, among other reasons. Req1 and this text under Req9 are in conflict. There is no way for a middlebox like the MR to look at anything else than the 5-tuples for doing traffic separation. Even without NEMO, your choices for providing differentiated treatment for IPsec packets are limited. Basically, its down to looking at addresses. (I think this would in fact most cases suffice, so I do not see the real world problem.) So if Req9 is about disallowing 5-tuple based policies, we have a problem. Perhaps you meant to say that RO still needs to be possible for unrecognized stuff, and that it then get some sort of default treatment. > 4.2. Des2 - Nesting > > > It is desirable if the RO mechanism supports RO for nested MRs, since > it is possible that for PIES and astronaut spacesuits, that PANs with > MRs will need to be supported. For oceanic flight, ATS and AOS may > also benefit from the capability of nesting MRs between multiple > planes to provide a "reachback" to terrestrial groundstations rather > than relying solely on lower rate HF or satellite systems. In either > case, this mode of operation is beyond current strict requirements > and is merely desirable. It is also noted that there are other ways > to support these communications scenarios using routing protocols or > other means outside of NEMO. Is loop detection a requirement? That is something that we do not currently support in NEMO... Editorial comments: > This document describes the requirements and desired properties of > NEMO Route Optimization techniques for use in global networked > communications systems for aeronautics and space exploration. > Expand NEMO in the title and abstract. > As background the NEMO terminology and NEMO goals and requirements > documents are suggested reading [4] [5]. The drafts produced as part > of the Mobile Platform Internet (MPI) effort are also of relevence, > and some of the material in this document is borrowed from the MPI > drafts [6] [7]. This part jumps out a little bit as the first paragraph, particularly when [6] and [7] are expired I-Ds. I would suggest the borrowing part should move to the acknowledgment section, and NEMO goals and requirements could be placed a little bit later in the Section, e.g., after the current second paragraph. > The base NEMO standard [1] allows Mobile IPv6 [2] to be used by > mobile routers, although NEMO does not support Mobile IPv6's Route > Optimization (RO) features for mobile network nodes other than the > NEMO Mobile Router (MR) itself. Again, the part that begins with "although" is a little bit early as you have not explained even the basic NEMO yet. Explain the basic NEMO first, and then put the lack of RO support to the end of the paragraph. > imposed by using the MRHA tunnel. Avoiding the delay from Expand the acronym MRHA before first use. > using Plain > Old Aircraft Communication Addressing and Reporting System (ACARS) > Unless "Plain Old" is the formal name, I would use "using the old Aircraft ..." instead. It would be good to get references to a few of the concepts and technologies. E.g., Section 2 talks about ACARDS, VDL modes, Electronic Flight Bags, B-AMC, AMACS, P34, LDL, WCDMA, 802.16, etc. Some of these acronyms were not defined either. > Both current and planned datalinks used > for PIES and/or AOS Undefined acronyms. > satcom links employed by Connexion by Boeing support much higher data rates than current ATS links. > Isn't this history now? I would suggest rephrasing this without any mention of specific products. E.g, satcom links employed by passenger Internet access systems support much higher... > it may tolerable be if some > special configuration is required for NEMO RO ... may be tolerable ... > new ATN architecture Expand the acronym and provide a reference if one exists. > As a minimum, if an RO solution is > integrable with the MONAMI6 basic extensions It would be better to find a non-WG name for these extensions. Please refer to draft-ietf-mext-multiplecoa specification, for instance. > (Note: this is particularly subject to MEXT discussion) > This should be removed or reformulated, as this draft becomes published as an RFC the context may no longer be there for the readers. Jari From alexandru.petrescu@gmail.com Wed Jun 17 08:53:02 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D53833A6DCE for ; Wed, 17 Jun 2009 08:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_OBFU_Q1=0.227] 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 dvU3QuMEMJHv for ; Wed, 17 Jun 2009 08:53:02 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 874483A6D6B for ; Wed, 17 Jun 2009 08:53:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n5HFos68011337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 Jun 2009 17:50:54 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n5HFr9gO029569; Wed, 17 Jun 2009 17:53:09 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n5HFr9UA013468; Wed, 17 Jun 2009 17:53:09 +0200 Message-ID: <4A391165.7010304@gmail.com> Date: Wed, 17 Jun 2009 17:53:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jari Arkko References: <4A380AB6.2080407@piuha.net> In-Reply-To: <4A380AB6.2080407@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-mext-aero-reqs@tools.ietf.org, "mext@ietf.org" Subject: Re: [MEXT] AD review of draft-ietf-mext-aero-reqs X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 15:53:02 -0000 Just one particular point about looping issues... Jari Arkko a écrit : [...] draft says: >> 4.2. Des2 - Nesting >> >> >> It is desirable if the RO mechanism supports RO for nested MRs, since >> it is possible that for PIES and astronaut spacesuits, that PANs with >> MRs will need to be supported. For oceanic flight, ATS and AOS may >> also benefit from the capability of nesting MRs between multiple >> planes to provide a "reachback" to terrestrial groundstations rather >> than relying solely on lower rate HF or satellite systems. In either >> case, this mode of operation is beyond current strict requirements >> and is merely desirable. It is also noted that there are other ways >> to support these communications scenarios using routing protocols or >> other means outside of NEMO. Jari says: > Is loop detection a requirement? That is something that we do not > currently support in NEMO... I am not sure what do you mean Jari, by saying that loop detection is not supported in NEMO(?) With Mobile IP based network mobility packets can not travel in loop paths (a typical risk of badly behaving distributed algorithm of path construction), simply because packets get encapsulated each time, every same-level path can't loop. On another hand, I am not aware of any analysis of Mobile IP based network mobility protocols from a looping standpoint. I wanted to point to a 'stalemate' situation described in RFC4888 Appendix B which shows a mobility configuration leading to impossibility to set up the MR-HA tunnel. This configuration can occur with a small capsule detaching from a larger station, attaching to another larger station; subsequently the initial station tries to attach to the capsule. This may lead to a 'stalemate' situation from the Mobile IP and RFC4888 standpoint. A NEMO RO protocol should help avoid this situation. I am wondering about similar description of what looping and NEMO can be in the framework of aero-reqs draft. Alex > > > Editorial comments: > >> This document describes the requirements and desired properties of >> NEMO Route Optimization techniques for use in global networked >> communications systems for aeronautics and space exploration. >> > > Expand NEMO in the title and abstract. > > >> As background the NEMO terminology and NEMO goals and requirements >> documents are suggested reading [4] [5]. The drafts produced as part >> of the Mobile Platform Internet (MPI) effort are also of relevence, >> and some of the material in this document is borrowed from the MPI >> drafts [6] [7]. > > This part jumps out a little bit as the first paragraph, particularly > when [6] and [7] are expired I-Ds. I would suggest the borrowing part > should move to the acknowledgment section, and NEMO goals and > requirements could be placed a little bit later in the Section, e.g., > after the current second paragraph. > >> The base NEMO standard [1] allows Mobile IPv6 [2] to be used by >> mobile routers, although NEMO does not support Mobile IPv6's Route >> Optimization (RO) features for mobile network nodes other than the >> NEMO Mobile Router (MR) itself. > > Again, the part that begins with "although" is a little bit early as you > have not explained even the basic NEMO yet. Explain the basic NEMO > first, and then put the lack of RO support to the end of the paragraph. > >> imposed by using the MRHA tunnel. Avoiding the delay from > > Expand the acronym MRHA before first use. > >> using Plain >> Old Aircraft Communication Addressing and Reporting System (ACARS) >> > > Unless "Plain Old" is the formal name, I would use "using the old > Aircraft ..." instead. > > It would be good to get references to a few of the concepts and > technologies. E.g., Section 2 talks about ACARDS, VDL modes, Electronic > Flight Bags, B-AMC, AMACS, P34, LDL, WCDMA, 802.16, etc. Some of these > acronyms were not defined either. > >> Both current and planned datalinks used >> for PIES and/or AOS > > Undefined acronyms. > >> satcom links employed by Connexion by Boeing support much higher data >> rates than current ATS links. >> > > Isn't this history now? I would suggest rephrasing this without any > mention of specific products. E.g, satcom links employed by passenger > Internet access systems support much higher... > >> it may tolerable be if some >> special configuration is required for NEMO RO > ... may be tolerable ... > > >> new ATN architecture > > > Expand the acronym and provide a reference if one exists. > >> As a minimum, if an RO solution is >> integrable with the MONAMI6 basic extensions > > It would be better to find a non-WG name for these extensions. Please > refer to draft-ietf-mext-multiplecoa specification, for instance. > >> (Note: this is particularly subject to MEXT discussion) >> > > This should be removed or reformulated, as this draft becomes published > as an RFC the context may no longer be there for the readers. > > Jari > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From w52006@huawei.com Wed Jun 17 19:41:58 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F553A6BFC for ; Wed, 17 Jun 2009 19:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-1.282, BAYES_05=-1.11, MANGLED_SIDE=2.3] 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 yCjpC0tpD2bd for ; Wed, 17 Jun 2009 19:41:57 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B8B0A3A6820 for ; Wed, 17 Jun 2009 19:41:57 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLE0097KY67LP@szxga04-in.huawei.com> for mext@ietf.org; Thu, 18 Jun 2009 10:42:08 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLE008C3Y673V@szxga04-in.huawei.com> for mext@ietf.org; Thu, 18 Jun 2009 10:42:07 +0800 (CST) Received: from w52006d ([10.164.12.17]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLE001AFY64AC@szxml06-in.huawei.com> for mext@ietf.org; Thu, 18 Jun 2009 10:42:07 +0800 (CST) Date: Thu, 18 Jun 2009 10:42:04 +0800 From: Yungui Wang In-reply-to: <4A106574.8040107@it.uc3m.es> To: 'mext' Message-id: <000001c9efbe$5d43f810$110ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnXJcXbG7LY0xerTje1j/btjd0iGwA/92Tg Subject: [MEXT] Comments to draft-tsirtsis-mext-binary-filters-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 02:41:58 -0000 Hello 1, Could the TLV/TV (type, length, value) format be used to encode the paramters in the IPv4/IPv6 Flow Description sub-option? Consideration: It may be not necessary to describe a flow which includes all the parameters in the Flow Description sub-options. At the same time, one parameter may appear multiple times in the sub-option for a flow. For example, a flow may be presented as TCP port 5000 and 5001. 2, Could the Ethernet service flow description sub-option be also introduced in this document? Consideration: The Ethernet service flow description sub-option is senseful when Ethernet service is supported by MIP (referring to http://www.ietf.org/internet-drafts/draft-wu-mip4-ether-02.txt ). The format of the Ethernet serice flow description sub-option is: - Ethernet serice flow description sub-option (TV format) 0x01 48bit,source MAC address 0x02 48bit,destination MAC address 0x03 16bit,ethernet type 0x04 16bit,vlan tag - Ethernet serice flow description sub-option (proto header format) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|D|E|V| Reservered | (S) Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (S) Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (D)Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |(D)Destination MAC Address | (E) Ethernet Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (V) VLAN tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B.R. Yungui From w52006@huawei.com Wed Jun 17 19:59:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29F53A68D0 for ; Wed, 17 Jun 2009 19:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[AWL=-1.219, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 Wyclq6wNzQXO for ; Wed, 17 Jun 2009 19:59:25 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id F40073A6820 for ; Wed, 17 Jun 2009 19:59:24 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLE0061WYZ2K1@szxga01-in.huawei.com> for mext@ietf.org; Thu, 18 Jun 2009 10:59:26 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLE002W0YZ2YX@szxga01-in.huawei.com> for mext@ietf.org; Thu, 18 Jun 2009 10:59:26 +0800 (CST) Received: from w52006d ([10.164.12.17]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLE001ZKYYZAC@szxml06-in.huawei.com> for mext@ietf.org; Thu, 18 Jun 2009 10:59:26 +0800 (CST) Date: Thu, 18 Jun 2009 10:59:23 +0800 From: Yungui Wang In-reply-to: To: 'Hesham Soliman' , mext@ietf.org Message-id: <000101c9efc0$c89161a0$110ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrAAAQQE8QAAMm/gAAF89IAAAUTo4AAAlIEQAAG4A/AAAOWmQAAAFuHgAAGc1aAAAELVEAAAxMVKAAAU1vAAI5XZLAABmRPA Subject: [MEXT] "buffer" action for flow binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 02:59:25 -0000 Hello There is a scenario for the HA service provider. One MN is watching a real-time TV service from internet. For mobile IP service, a video flow is created on HA. At the time, a video call is incoming, the MN decides to response the call and pause the TV service. Due to lack of bandwidth he can't receive and buffer it locally. He may then ask the HA buffering the TV flow un-interruptted. Thus, new action "Buffer" may be needed for flow binding. 4 Buffer. This value indicates a request to buffer all packets in the flow described by the option. No BIDs are associated with this Action. Does it make sense? B.R. Yungui From hesham@elevatemobile.com Wed Jun 17 20:09:44 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02CA73A6820 for ; Wed, 17 Jun 2009 20:09:44 -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=[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 cjGZZa3KKVzM for ; Wed, 17 Jun 2009 20:09:43 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 2DBBB3A657C for ; Wed, 17 Jun 2009 20:09:42 -0700 (PDT) Received: from [122.110.175.166] (helo=[192.168.0.3]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MH80c-0000vo-0o; Thu, 18 Jun 2009 13:09:51 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 18 Jun 2009 13:09:42 +1000 From: Hesham Soliman To: , Message-ID: Thread-Topic: [MEXT] "buffer" action for flow binding Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrAAAQQE8QAAMm/gAAF89IAAAUTo4AAAlIEQAAG4A/AAAOWmQAAAFuHgAAGc1aAAAELVEAAAxMVKAAAU1vAAI5XZLAABmRPAAYmLnDs= In-Reply-To: <000101c9efc0$c89161a0$110ca40a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [MEXT] "buffer" action for flow binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 03:09:44 -0000 > There is a scenario for the HA service provider. > > One MN is watching a real-time TV service from internet. For > mobile IP service, > a video flow is created on HA. At the time, a video call is > incoming, the MN > decides to response the call and pause the TV service. Due to > lack of > bandwidth he can't receive and buffer it locally. He may then ask > the HA > buffering the TV flow un-interruptted. Thus, new action "Buffer" > may be > needed for flow binding. > > 4 Buffer. This value indicates a request to buffer all packets > in the flow described by the option. No BIDs are associated > with > this Action. > > Does it make sense? => I'm not sure about that specific scenario but I think buffering is potentially a useful action. A couple of things we need to address in order to introduce this action: 1. How long do you buffer? I assume this has to be explicitly said in the BU. It could be a certain amount of time, an automatic buffer/release mechanism ...etc. We need to know what to do with this. 2. If you're buffering for some time I assume you need a release message? It would be helpful if you/others can help with answering these questions. Hesham > > > B.R. > Yungui > > From w52006@huawei.com Wed Jun 17 20:59:42 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22AA03A6A5A for ; Wed, 17 Jun 2009 20:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 CMRm4ngDe5WJ for ; Wed, 17 Jun 2009 20:59:41 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 5D7393A6A3A for ; Wed, 17 Jun 2009 20:59:41 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLF004JV1RJ6I@szxga03-in.huawei.com> for mext@ietf.org; Thu, 18 Jun 2009 11:59:43 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLF0097F1RJAJ@szxga03-in.huawei.com> for mext@ietf.org; Thu, 18 Jun 2009 11:59:43 +0800 (CST) Received: from w52006d ([10.164.12.17]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLF008KN1RFJV@szxml04-in.huawei.com> for mext@ietf.org; Thu, 18 Jun 2009 11:59:43 +0800 (CST) Date: Thu, 18 Jun 2009 11:59:39 +0800 From: Yungui Wang In-reply-to: To: 'Hesham Soliman' , mext@ietf.org Message-id: <000301c9efc9$344127c0$110ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrAAAQQE8QAAMm/gAAF89IAAAUTo4AAAlIEQAAG4A/AAAOWmQAAAFuHgAAGc1aAAAELVEAAAxMVKAAAU1vAAI5XZLAABmRPAAYmLnDsAAFPhMA== Subject: Re: [MEXT] "buffer" action for flow binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 03:59:42 -0000 Hello > => I'm not sure about that specific scenario but I think > buffering is potentially a useful action. A couple of things > we need to address in order to introduce this action: > 1. How long do you buffer? I assume this has to be explicitly > said in the BU. It could be a certain amount of time, an > automatic buffer/release mechanism ...etc. We need to know > what to do with this. Yeah. If supported, it is necessary to extend the Flow Identifier option to include some flow attributes, such as time and/or volume. > > 2. If you're buffering for some time I assume you need a > release message? > There are two possible options: 1. Implicitly mode. It can be deleted when time is out, or when it has been completely downloaded, or the flow binding is de-registered, etc. 2. Explicitly mode. It needs to be explicitly deleted. B.R. Yungui From yuri.ismailov@ericsson.com Thu Jun 18 02:05:01 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F130028C140 for ; Thu, 18 Jun 2009 02:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.892 X-Spam-Level: X-Spam-Status: No, score=-6.892 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 eeFlzcT43L1a for ; Thu, 18 Jun 2009 02:05:01 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 43C6728C254 for ; Thu, 18 Jun 2009 02:04:57 -0700 (PDT) X-AuditID: c1b4fb3e-b7b55ae0000025f6-7c-4a3a00725e6b Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id F0.CE.09718.2700A3A4; Thu, 18 Jun 2009 10:53:06 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jun 2009 10:53:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jun 2009 10:53:04 +0200 Message-ID: In-Reply-To: <000101c9efc0$c89161a0$110ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] "buffer" action for flow binding Thread-Index: AcnjmVArXuHlqpB6ReK+MNuOgiq+ngAeSVlgAAD1kwcAADZBwAAA4UsmAAArcMAAAdgk/AACQqKgAAEfILUAAY3O0AABhK6MAAJw7NAAA6Ef1AAAIs0wABi03Y4AGEqFIAACL7m5ACRpEyAAA1xL5AAAVnNgAAl4jDAAiZROkAAIfiihAAQX5+AAARv3TAAhxyJQAAIosu8AADiB8AABrbkMAACiIrAAAQQE8QAAMm/gAAF89IAAAUTo4AAAlIEQAAG4A/AAAOWmQAAAFuHgAAGc1aAAAELVEAAAxMVKAAAU1vAAI5XZLAABmRPAAZPdMyA= References: <000101c9efc0$c89161a0$110ca40a@china.huawei.com> From: "Yuri Ismailov" To: , "Hesham Soliman" , X-OriginalArrivalTime: 18 Jun 2009 08:53:04.0636 (UTC) FILETIME=[316163C0:01C9EFF2] X-Brightmail-Tracker: AAAAAA== Subject: Re: [MEXT] "buffer" action for flow binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 09:05:02 -0000 Hi folks, It looks like that the propsal is to extend mobility support with pure application function. Do not think one can discuss this seriously within this group. Can somebody imagine that video stream buffering may become a router function, for example? What I can understand is that buffering does not have to have end-to-end semantics and may be performed by a proxy, but this is an application proxy, which is application specific, thus understand application layer protocol. For this proposal to work, one will have to implement application layer gateway in HA, because it (HA) has to understand what it buffers. At IP layer packets may be disordered, for example, and the buffered content by HA will not make any sense for later use. Regards Yuri -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Yungui Wang Sent: Thursday, June 18, 2009 4:59 AM To: 'Hesham Soliman'; mext@ietf.org Subject: [MEXT] "buffer" action for flow binding Hello There is a scenario for the HA service provider. One MN is watching a real-time TV service from internet. For mobile IP service, a video flow is created on HA. At the time, a video call is incoming, the MN decides to response the call and pause the TV service. Due to lack of bandwidth he can't receive and buffer it locally. He may then ask the HA buffering the TV flow un-interruptted. Thus, new action "Buffer" may be needed for flow binding. 4 Buffer. This value indicates a request to buffer all packets in the flow described by the option. No BIDs are associated with this Action. Does it make sense? B.R. Yungui _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From julien.laganier.ietf@googlemail.com Thu Jun 18 05:06:28 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 341F628C273 for ; Thu, 18 Jun 2009 05:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 yRFU6z4JBx7Z for ; Thu, 18 Jun 2009 05:06:27 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id BD94128C316 for ; Thu, 18 Jun 2009 05:06:26 -0700 (PDT) Received: by bwz9 with SMTP id 9so1005089bwz.37 for ; Thu, 18 Jun 2009 05:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=YDLOjU+0yEBDZoIah8I7jjPHFvOAXKJDPmmwwcDpwK8=; b=I10icLqkmzdUa2xOfjWNzKUu/1URYuSAej/A7X0bQxY73eVMBOGPRd/XmxoZoY5Ucx 3sVzBwJ8n5oshw2Al3jlz9xv5aMwpSVPS2KsMviyXznHvJLlTI08Tpiu+UBhosHJTTpc MuQVwGzVc9b43Uz7H3j1I/1lWovbW0Wz48K/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NrowWcMtlaRV1+c9eZXrVtdo0UgTfGXqHIJJjhxDYO+yvVb5Bm2NgnUxnYHOO5bDnO /ZcaxuBhNm2Um3WSRCbHjZIoaG1uZYOpn8H/XTfQncBHNcDV7/qbZfu0Xzdtjar76lbY FI7MV0HJqiOoOCUR1FoCG0FM9SH0Z9Zqj+S6I= MIME-Version: 1.0 Received: by 10.204.66.17 with SMTP id l17mr1308395bki.44.1245326796419; Thu, 18 Jun 2009 05:06:36 -0700 (PDT) In-Reply-To: <000101c9efc0$c89161a0$110ca40a@china.huawei.com> References: <000101c9efc0$c89161a0$110ca40a@china.huawei.com> Date: Thu, 18 Jun 2009 14:06:36 +0200 Message-ID: <7ad6d6db0906180506u6193a66fh85ce4438f9ca8215@mail.gmail.com> From: Julien Laganier To: w52006@huawei.com Content-Type: multipart/alternative; boundary=001636c5bbd15471ac046c9e3d5f Cc: mext@ietf.org Subject: Re: [MEXT] "buffer" action for flow binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 12:06:28 -0000 --001636c5bbd15471ac046c9e3d5f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Another potential usecase for buffering would be as follows: MN is receiving and/or sending bulk data transfer over TCP. Prior to handover it requests HA to buffer downlink packets. After Handover it requests HA to resume transmission of packets. In that way no TCP packets are lost because sent at the old MN CoA, and TCP transmission rate is less impacted or not impacted at all by the handover. --julien On Thu, Jun 18, 2009 at 4:59 AM, Yungui Wang wrote: > Hello > > There is a scenario for the HA service provider. > > One MN is watching a real-time TV service from internet. For > mobile IP service, > a video flow is created on HA. At the time, a video call is > incoming, the MN > decides to response the call and pause the TV service. Due to > lack of > bandwidth he can't receive and buffer it locally. He may then ask > the HA > buffering the TV flow un-interruptted. Thus, new action "Buffer" > may be > needed for flow binding. > > 4 Buffer. This value indicates a request to buffer all packets > in the flow described by the option. No BIDs are associated > with > this Action. > > Does it make sense? > > > B.R. > Yungui > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > --001636c5bbd15471ac046c9e3d5f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Another potential usecase for buffering would be as follows:

MN is r= eceiving and/or sending bulk data transfer over TCP. Prior to handover it r= equests HA to buffer downlink packets. After Handover it requests HA to res= ume transmission of packets. In that way no TCP packets are lost because se= nt at the old MN CoA, and TCP transmission rate is less impacted or not imp= acted at all by the handover.

--julien

On Thu, Jun 18, 2009 at 4:59= AM, Yungui Wang <w52006@huawei.com> wrote:
Hello

There is a scenario for the HA service provider.

One MN is watching a real-time TV service from internet. For
mobile IP service,
a video flow is created on HA. At the time, a video call is
incoming, the MN
decides to response the call and pause the TV service. =A0Due to
lack of
bandwidth he can't receive and buffer it locally. He may then ask
the HA
buffering the TV flow un-interruptted. Thus, new action "Buffer"<= br> may be
needed for flow binding.

4 Buffer. =A0This value indicates a request to buffer all packets
=A0 =A0 =A0in the flow described by the option. =A0No BIDs are associated<= br> with
=A0 =A0 =A0this Action.

Does it make sense?


B.R.
Yungui


_______________________________________________
MEXT mailing list
MEXT@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mext

--001636c5bbd15471ac046c9e3d5f-- From behcetsarikaya@yahoo.com Thu Jun 18 08:46:40 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4188D28C3C9 for ; Thu, 18 Jun 2009 08:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.803 X-Spam-Level: X-Spam-Status: No, score=-1.803 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 3qfrWg39NVFR for ; Thu, 18 Jun 2009 08:46:39 -0700 (PDT) Received: from n69.bullet.mail.sp1.yahoo.com (n69.bullet.mail.sp1.yahoo.com [98.136.44.41]) by core3.amsl.com (Postfix) with SMTP id 6B3893A6814 for ; Thu, 18 Jun 2009 08:46:39 -0700 (PDT) Received: from [216.252.122.219] by n69.bullet.mail.sp1.yahoo.com with NNFMP; 18 Jun 2009 15:46:50 -0000 Received: from [67.195.9.83] by t4.bullet.sp1.yahoo.com with NNFMP; 18 Jun 2009 15:46:50 -0000 Received: from [67.195.9.101] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 18 Jun 2009 15:46:50 -0000 Received: from [127.0.0.1] by omp105.mail.gq1.yahoo.com with NNFMP; 18 Jun 2009 15:46:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 353027.57375.bm@omp105.mail.gq1.yahoo.com Received: (qmail 2384 invoked by uid 60001); 18 Jun 2009 15:46:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245340010; bh=RWbUTejQJtVhDx47AJO5UwBYTS1i/2dIljia9YODumw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QB8h23fPvm5Lih8pNB6dZvKSl+gsSdk9r5dGA/aOpakg+Vk+4lBMHlhArgOTbM1p3ruGBkAfioifzH2ceY/cfmuNGDdj62RFwCAaZ7ne/Z9JrjiL5Hm50L9OGh4hopgv1432/It3TObSmBCsPz8VhFn6+CE0aF28J/NhS+4KuJY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xMHsds3mydFi0mrpIbvk9rsbPCGvCQt0r9YF6yiUhVvfMvFPYbXI5Q7BpJBp4ZvTg+P8T6vVYMA/7xq9W3E0Kc+M5R6ZPtnrw9UBIYaKJJGdT66sl+6JMUJUZ8KWELnlzaImbo7dEL5UCKRpkh65zziIh249jMY9bb06AQi8pBQ=; Message-ID: <140086.1640.qm@web111401.mail.gq1.yahoo.com> X-YMail-OSG: wsoFWAYVM1keFR8oMLKTFp57ZL5XtpsRh1u4o3289KWjnPOi39lAQVWLWtT6a5kt9v9FT0PWqp4UCq4N1hla3WmfkQE5Ccj72fvJ5ggpsZe2ie9Cvf36aGxUv_MbpK_VVct6HIj3SVU_3.CFrg9OWELwN0I2rafaJZuCeFRhKhjs9o8FPtw_sSmqeHiD6.lHNRO6jyycSdj2_Gx5DwSOmW1PX7U00pfq1eFXzcwsz3KTanV_.cLg08IUABm1.AgjG4i1SdwNzQX7x4kHEP_ufjVhboKoTa1hn3L1ambV.rZtv0XJMOwh.AZuSnr0NmVO_HNqI1H7FI0HyjOEUDafBSDAFg-- Received: from [206.16.17.212] by web111401.mail.gq1.yahoo.com via HTTP; Thu, 18 Jun 2009 08:46:50 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 References: <000101c9efc0$c89161a0$110ca40a@china.huawei.com> <7ad6d6db0906180506u6193a66fh85ce4438f9ca8215@mail.gmail.com> Date: Thu, 18 Jun 2009 08:46:50 -0700 (PDT) From: Behcet Sarikaya To: Julien Laganier , w52006@huawei.com In-Reply-To: <7ad6d6db0906180506u6193a66fh85ce4438f9ca8215@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-472933316-1245340010=:1640" Cc: mext@ietf.org Subject: Re: [MEXT] "buffer" action for flow binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 15:46:40 -0000 --0-472933316-1245340010=:1640 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Folks,=0A=A0 We had a draft on HA buffering, it is at:=0Ahttp://tools.ietf.= org/html/draft-xia-mipshop-ha-buffering-01=0A=0ARegards,=0A=0ABehcet=0A=0A= =0A=0A=0A________________________________=0AFrom: Julien Laganier =0ATo: w52006@huawei.com=0ACc: mext@ietf.org=0A= Sent: Thursday, June 18, 2009 7:06:36 AM=0ASubject: Re: [MEXT] "buffer" act= ion for flow binding=0A=0AAnother potential usecase for buffering would be = as follows:=0A=0AMN is receiving and/or sending bulk data transfer over TCP= .. Prior to handover it requests HA to buffer downlink packets. After Handov= er it requests HA to resume transmission of packets. In that way no TCP pac= kets are lost because sent at the old MN CoA, and TCP transmission rate is = less impacted or not impacted at all by the handover.=0A=0A--julien=0A=0A= =0AOn Thu, Jun 18, 2009 at 4:59 AM, Yungui Wang wrote:= =0A=0AHello=0A=0AThere is a scenario for the HA service provider.=0A=0AOne = MN is watching a real-time TV service from internet. For=0Amobile IP servic= e,=0Aa video flow is created on HA. At the time, a video call is=0Aincoming= , the MN=0Adecides to response the call and pause the TV service. =A0Due to= =0Alack of=0Abandwidth he can't receive and buffer it locally. He may then = ask=0Athe HA=0Abuffering the TV flow un-interruptted. Thus, new action "Buf= fer"=0Amay be=0Aneeded for flow binding.=0A=0A4 Buffer. =A0This value indic= ates a request to buffer all packets=0A=A0 =A0 =A0in the flow described by = the option. =A0No BIDs are associated=0Awith=0A=A0 =A0 =A0this Action.=0A= =0ADoes it make sense?=0A=0A=0AB.R.=0AYungui=0A=0A=0A______________________= _________________________=0AMEXT mailing list=0AMEXT@ietf.org=0Ahttps://www= ..ietf.org/mailman/listinfo/mext=0A=0A=0A --0-472933316-1245340010=:1640 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Folks,
=0A
  We had a draft on HA buffer= ing, it is at:
=0A=0A
 
=0A
Regards,
=0A
&nbs= p;
=0A
Behcet
=0A

=0A
=0A
=0AFro= m: Julien Laganier <julien.laganier.ietf@googlemail.com>To: w52006@huawei.com
= Cc: mext@ietf.org
Sent: Thursday, June 18, 2009 7:0= 6:36 AM
Subject: Re: [ME= XT] "buffer" action for flow binding

Another potential usecas= e for buffering would be as follows:

MN is receiving and/or sending = bulk data transfer over TCP. Prior to handover it requests HA to buffer dow= nlink packets. After Handover it requests HA to resume transmission of pack= ets. In that way no TCP packets are lost because sent at the old MN CoA, an= d TCP transmission rate is less impacted or not impacted at all by the hand= over.

--julien

=0A
On Thu, Jun 18, 20= 09 at 4:59 AM, Yungui Wang <w52006@huawei.com> wrote:
=0A
Hello

There is a scenario for the HA servi= ce provider.

One MN is watching a real-time TV service from internet= .. For
mobile IP service,
a video flow is created on HA. At the time, = a video call is
incoming, the MN
decides to response the call and pau= se the TV service.  Due to
lack of
bandwidth he can't receive an= d buffer it locally. He may then ask
the HA
buffering the TV flow un-= interruptted. Thus, new action "Buffer"
may be
needed for flow bindin= g.

4 Buffer.  This value indicates a request to buffer all pack= ets
     in the flow described by the option.  No BI= Ds are associated
with
     this Action.

Does i= t make sense?


B.R.
Yungui


________________________= _______________________
MEXT mailing list
MEXT@ietf.org
https://www.= ietf.org/mailman/listinfo/mext


=0A=0A=0A=0A --0-472933316-1245340010=:1640-- From wesley.m.eddy@nasa.gov Thu Jun 18 10:17:18 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F35C28C3C9 for ; Thu, 18 Jun 2009 10:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 CLm8LhPtfVvs for ; Thu, 18 Jun 2009 10:17:17 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 1578828C321 for ; Thu, 18 Jun 2009 10:17:17 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id C645078271; Thu, 18 Jun 2009 12:17:28 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01.ndc.nasa.gov [198.117.4.160]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n5IHHS0M030682; Thu, 18 Jun 2009 12:17:28 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.4.160]) with mapi; Thu, 18 Jun 2009 12:17:28 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: Julien Laganier , "w52006@huawei.com" Date: Thu, 18 Jun 2009 12:15:32 -0500 Thread-Topic: [MEXT] "buffer" action for flow binding Thread-Index: AcnwDUZLfp/TSZoBTNKwoqylcy5RlQAKcZvw Message-ID: References: <000101c9efc0$c89161a0$110ca40a@china.huawei.com> <7ad6d6db0906180506u6193a66fh85ce4438f9ca8215@mail.gmail.com> In-Reply-To: <7ad6d6db0906180506u6193a66fh85ce4438f9ca8215@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-06-18_11:2009-06-01, 2009-06-18, 2009-06-18 signatures=0 Cc: "mext@ietf.org" Subject: Re: [MEXT] "buffer" action for flow binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 17:17:18 -0000 I wouldn't advise trying to do too much optimization on behalf of TCP. It depends on the length of time to perform the handover, but longish handovers can run near the RTO and the data needing buffering during bulk-transfer is limited by the ACKs already in-flight before handover due to the data segments being clocked out by ACKs. For shorter handovers, TCP can handle the loss detection and recovery efficiently through the fast retransmission/recovery and SACK procedures. There is also an argument some have made that TCP should be re- initiating slow-start from its initial window after handovers due to the fact that the path has completely changed and the state established on the old path (cwnd, ssthresh, RTT, PMTU) may be invalid. Just a bit of caution and skepticism that buffering at the HA will work exactly as intended in all cases ... even in the best case, the buffering will cause an RTT spike. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- >-----Original Message----- >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of >Julien Laganier >Sent: Thursday, June 18, 2009 8:07 AM >To: w52006@huawei.com >Cc: mext@ietf.org >Subject: Re: [MEXT] "buffer" action for flow binding > >Another potential usecase for buffering would be as follows: > >MN is receiving and/or sending bulk data transfer over TCP. Prior to >handover it requests HA to buffer downlink packets. After Handover it >requests HA to resume transmission of packets. In that way no TCP >packets are lost because sent at the old MN CoA, and TCP transmission >rate is less impacted or not impacted at all by the handover. > >--julien > > >On Thu, Jun 18, 2009 at 4:59 AM, Yungui Wang wrote: > > > Hello > > There is a scenario for the HA service provider. > > One MN is watching a real-time TV service from internet. For > mobile IP service, > a video flow is created on HA. At the time, a video call is > incoming, the MN > decides to response the call and pause the TV service. Due to > lack of > bandwidth he can't receive and buffer it locally. He may then ask > the HA > buffering the TV flow un-interruptted. Thus, new action "Buffer" > may be > needed for flow binding. > > 4 Buffer. This value indicates a request to buffer all packets > in the flow described by the option. No BIDs are associated > with > this Action. > > Does it make sense? > > > B.R. > Yungui > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From tsirtsis@googlemail.com Thu Jun 18 14:30:09 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890FF3A6BAE for ; Thu, 18 Jun 2009 14:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 U0ABn6s95Kng for ; Thu, 18 Jun 2009 14:30:08 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id C466C3A65A6 for ; Thu, 18 Jun 2009 14:30:07 -0700 (PDT) Received: by bwz9 with SMTP id 9so1400196bwz.37 for ; Thu, 18 Jun 2009 14:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YOkxAVT8s7SYhH+PgNbJNV+HUVix00c2FJw+5rXoypI=; b=wHMPHlhrj/32JA7zNwCXKiGbMjiIsgPbaktp+7BCMAitF0aZtpuOhN1YPfZpqDV3XZ WbSGqgSASxIzLvG/BWRriepNG+5oTftZWC49ingd7Ptpi2EtuFcROZD4UCBawOvxsGFm btosjL7PglQvnVJ19cy1Uuw0BByZxsXLiGzEs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ndnrcEeDkNeENyptcoNvtNzyN0Ln6wgYc1m41ud/7GMOBO/vp3eiwu0XFbEB3l7c0y thS+gfSbIta9aCdL3vSN+qWbN57cFzrRSgm8Bme0EdpFiDINbOF9KbbDeQcMohFlJNr2 Wbd44+v0BHrJuKmPgskjiJ1Oorlr0ubW9do5c= MIME-Version: 1.0 Received: by 10.223.114.208 with SMTP id f16mr1725285faq.91.1245360616949; Thu, 18 Jun 2009 14:30:16 -0700 (PDT) In-Reply-To: References: <000101c9efc0$c89161a0$110ca40a@china.huawei.com> <7ad6d6db0906180506u6193a66fh85ce4438f9ca8215@mail.gmail.com> Date: Thu, 18 Jun 2009 22:30:16 +0100 Message-ID: From: George Tsirtsis To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "mext@ietf.org" , Julien Laganier Subject: Re: [MEXT] "buffer" action for flow binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 21:30:10 -0000 I second this. I am not convinced that buffering at the HA is helpful. why would one thing that buffering in the HA will reducing buffering requirements in the MN? I also second other peoples' comments regarding the feasibility of buffering application flows on a router. In general I think this is beyond the scope of Mobile IP and MEXT and is taking us into APP-area. George On Thu, Jun 18, 2009 at 6:15 PM, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > I wouldn't advise trying to do too much optimization on behalf > of TCP. =C2=A0It depends on the length of time to perform the > handover, but longish handovers can run near the RTO and the > data needing buffering during bulk-transfer is limited by the > ACKs already in-flight before handover due to the data segments > being clocked out by ACKs. =C2=A0For shorter handovers, TCP can > handle the loss detection and recovery efficiently through the > fast retransmission/recovery and SACK procedures. =C2=A0There is > also an argument some have made that TCP should be re- > initiating slow-start from its initial window after handovers > due to the fact that the path has completely changed and the > state established on the old path (cwnd, ssthresh, RTT, PMTU) > may be invalid. > > Just a bit of caution and skepticism that buffering at the HA > will work exactly as intended in all cases ... even in the > best case, the buffering will cause an RTT spike. > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > > >>-----Original Message----- >>From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of >>Julien Laganier >>Sent: Thursday, June 18, 2009 8:07 AM >>To: w52006@huawei.com >>Cc: mext@ietf.org >>Subject: Re: [MEXT] "buffer" action for flow binding >> >>Another potential usecase for buffering would be as follows: >> >>MN is receiving and/or sending bulk data transfer over TCP. Prior to >>handover it requests HA to buffer downlink packets. After Handover it >>requests HA to resume transmission of packets. In that way no TCP >>packets are lost because sent at the old MN CoA, and TCP transmission >>rate is less impacted or not impacted at all by the handover. >> >>--julien >> >> >>On Thu, Jun 18, 2009 at 4:59 AM, Yungui Wang wrote: >> >> >> =C2=A0 =C2=A0 =C2=A0 Hello >> >> =C2=A0 =C2=A0 =C2=A0 There is a scenario for the HA service provider. >> >> =C2=A0 =C2=A0 =C2=A0 One MN is watching a real-time TV service from inte= rnet. For >> =C2=A0 =C2=A0 =C2=A0 mobile IP service, >> =C2=A0 =C2=A0 =C2=A0 a video flow is created on HA. At the time, a video= call is >> =C2=A0 =C2=A0 =C2=A0 incoming, the MN >> =C2=A0 =C2=A0 =C2=A0 decides to response the call and pause the TV servi= ce. =C2=A0Due to >> =C2=A0 =C2=A0 =C2=A0 lack of >> =C2=A0 =C2=A0 =C2=A0 bandwidth he can't receive and buffer it locally. H= e may then ask >> =C2=A0 =C2=A0 =C2=A0 the HA >> =C2=A0 =C2=A0 =C2=A0 buffering the TV flow un-interruptted. Thus, new ac= tion "Buffer" >> =C2=A0 =C2=A0 =C2=A0 may be >> =C2=A0 =C2=A0 =C2=A0 needed for flow binding. >> >> =C2=A0 =C2=A0 =C2=A0 4 Buffer. =C2=A0This value indicates a request to b= uffer all packets >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the flow described by the op= tion. =C2=A0No BIDs are associated >> =C2=A0 =C2=A0 =C2=A0 with >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this Action. >> >> =C2=A0 =C2=A0 =C2=A0 Does it make sense? >> >> >> =C2=A0 =C2=A0 =C2=A0 B.R. >> =C2=A0 =C2=A0 =C2=A0 Yungui >> >> >> =C2=A0 =C2=A0 =C2=A0 _______________________________________________ >> =C2=A0 =C2=A0 =C2=A0 MEXT mailing list >> =C2=A0 =C2=A0 =C2=A0 MEXT@ietf.org >> =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/mext >> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From behcetsarikaya@yahoo.com Thu Jun 18 15:42:17 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC573A67ED for ; Thu, 18 Jun 2009 15:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 jas0S1HJFt+J for ; Thu, 18 Jun 2009 15:42:16 -0700 (PDT) Received: from n1.bullet.mail.re3.yahoo.com (n1.bullet.mail.re3.yahoo.com [68.142.237.108]) by core3.amsl.com (Postfix) with SMTP id D14D43A67AF for ; Thu, 18 Jun 2009 15:42:15 -0700 (PDT) Received: from [68.142.237.90] by n1.bullet.mail.re3.yahoo.com with NNFMP; 18 Jun 2009 22:42:26 -0000 Received: from [67.195.9.82] by t6.bullet.re3.yahoo.com with NNFMP; 18 Jun 2009 22:42:26 -0000 Received: from [67.195.9.111] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 18 Jun 2009 22:42:26 -0000 Received: from [127.0.0.1] by omp115.mail.gq1.yahoo.com with NNFMP; 18 Jun 2009 22:42:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 826302.19778.bm@omp115.mail.gq1.yahoo.com Received: (qmail 51778 invoked by uid 60001); 18 Jun 2009 22:42:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245364945; bh=wfOv6L833+g3f15s5Qo1d7scLFfSRxEqsiZ/E5qBhc8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MrlDht3mG5il5JeQ136AZj+GHgTQX1fdOO7Rpx+5UY8xJhtAiMg2GL1fdsG8lqc9pYDcs2EjRcfk/CBFST1G3r4bKyh8s0dv6gt+vNt7+A8IstMrfiUwqHcZ1GiyYqLkeeCELOR5hEh410bKwHT5hl1XHbPnt7ZCG6scCt5KAfU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gWjm/CkrNB628nrfkhkW4aESM7pO7Gbfjm9NOe1WLalxqwvag4fMl9TGBchy+Q1c9c/ZYh9nissKpA7Hv5pKrfdPUfE7Pq+82vQ+i4zxfI5FFbMF/7W3iQ8e3JdCmVi3HnLVhim3ior+v0lSe+xDpzW0bjKtfCtPS/Sx7qWOzvQ=; Message-ID: <786751.49101.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: eqya9W8VM1n_ptJB.kes21ujb5luy038EI.3tO2s8ZWUgaszSQzBtWdyKF2HZTxb7DiB6rjVAZ05jQxuAxvlBV5S7Dym99Cm7NnZRBsriLS2A3ynKEfSnsZPLEqcS0a0lgSgZi1YUCq0R_Gwt7fXBAWeCU2c3xK.plFT3ZFOdNv.qnbwKJL.bcJ6waF4RLQqOAjTs5PVdFQyUYMOELEZ6TFMsOVAY7Qp2.DDYcE3I8iI_ATqt8oUlAEHBVbruZJ4wip5b6UQ6lB6PDxSfWpSqEnheQoudyKWlYBKQJdbMkRl5uxU_hBu3B_EgyvencS5_kwxFDAtRNWROtjX3hh0H_Gevw-- Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Thu, 18 Jun 2009 15:42:25 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 References: <000101c9efc0$c89161a0$110ca40a@china.huawei.com> <7ad6d6db0906180506u6193a66fh85ce4438f9ca8215@mail.gmail.com> Date: Thu, 18 Jun 2009 15:42:25 -0700 (PDT) From: Behcet Sarikaya To: "Eddy, Wesley M. \(GRC-MS00\)\[Verizon\]" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mext@ietf.org" Subject: Re: [MEXT] "buffer" action for flow binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 22:42:17 -0000 Hi Eddy,=0A=A0 Thank you for your advice.=0AHowever, I would like to know i= f you have any experimental data, research, published papers, material to b= ack it up. Please let us know. I know that TCP behaviour in wireless links = has been studied in depth but I for one am not aware of any work on TCP and= MIPv6 type of things, especially in this context.=0A=0ARegards,=0A=0ABehce= t=0A=0A=0A=0A----- Original Message ----=0A> From: "Eddy, Wesley M. (GRC-MS= 00)[Verizon]" =0A> To: Julien Laganier ; "w52006@huawei.com" =0A> Cc: = "mext@ietf.org" =0A> Sent: Thursday, June 18, 2009 12:15:32 = PM=0A> Subject: Re: [MEXT] "buffer" action for flow binding=0A> =0A> I woul= dn't advise trying to do too much optimization on behalf=0A> of TCP.=A0 It = depends on the length of time to perform the=0A> handover, but longish hand= overs can run near the RTO and the=0A> data needing buffering during bulk-t= ransfer is limited by the=0A> ACKs already in-flight before handover due to= the data segments=0A> being clocked out by ACKs.=A0 For shorter handovers,= TCP can=0A> handle the loss detection and recovery efficiently through the= =0A> fast retransmission/recovery and SACK procedures.=A0 There is=0A> also= an argument some have made that TCP should be re-=0A> initiating slow-star= t from its initial window after handovers=0A> due to the fact that the path= has completely changed and the=0A> state established on the old path (cwnd= , ssthresh, RTT, PMTU)=0A> may be invalid.=0A> =0A> Just a bit of caution a= nd skepticism that buffering at the HA=0A> will work exactly as intended in= all cases ... even in the=0A> best case, the buffering will cause an RTT s= pike.=0A> =0A> ---------------------------=0A> Wes Eddy=0A> Network & Syste= ms Architect=0A> Verizon FNS / NASA GRC=0A> Office: (216) 433-6682=0A> ----= -----------------------=0A> =0A> =0A> >-----Original Message-----=0A> >From= : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of=0A> >Ju= lien Laganier=0A> >Sent: Thursday, June 18, 2009 8:07 AM=0A> >To: w52006@hu= awei.com=0A> >Cc: mext@ietf.org=0A> >Subject: Re: [MEXT] "buffer" action fo= r flow binding=0A> >=0A> >Another potential usecase for buffering would be = as follows:=0A> >=0A> >MN is receiving and/or sending bulk data transfer ov= er TCP. Prior to=0A> >handover it requests HA to buffer downlink packets. A= fter Handover it=0A> >requests HA to resume transmission of packets. In tha= t way no TCP=0A> >packets are lost because sent at the old MN CoA, and TCP = transmission=0A> >rate is less impacted or not impacted at all by the hando= ver.=0A> >=0A> >--julien=0A> >=0A> >=0A> >On Thu, Jun 18, 2009 at 4:59 AM, = Yungui Wang wrote:=0A> >=0A> >=0A> >=A0=A0=A0 Hello=0A> >=0A> >=A0=A0=A0 Th= ere is a scenario for the HA service provider.=0A> >=0A> >=A0=A0=A0 One MN = is watching a real-time TV service from internet. For=0A> >=A0=A0=A0 mobile= IP service,=0A> >=A0=A0=A0 a video flow is created on HA. At the time, a v= ideo call is=0A> >=A0=A0=A0 incoming, the MN=0A> >=A0=A0=A0 decides to resp= onse the call and pause the TV service.=A0 Due to=0A> >=A0=A0=A0 lack of=0A= > >=A0=A0=A0 bandwidth he can't receive and buffer it locally. He may then = ask=0A> >=A0=A0=A0 the HA=0A> >=A0=A0=A0 buffering the TV flow un-interrupt= ted. Thus, new action "Buffer"=0A> >=A0=A0=A0 may be=0A> >=A0=A0=A0 needed = for flow binding.=0A> >=0A> >=A0=A0=A0 4 Buffer.=A0 This value indicates a = request to buffer all packets=0A> >=A0=A0=A0 =A0 =A0 in the flow described = by the option.=A0 No BIDs are associated=0A> >=A0=A0=A0 with=0A> >=A0=A0=A0= =A0 =A0 this Action.=0A> >=0A> >=A0=A0=A0 Does it make sense?=0A> >=0A> >= =0A> >=A0=A0=A0 B.R.=0A> >=A0=A0=A0 Yungui=0A> >=0A> >=0A> >=A0=A0=A0 _____= __________________________________________=0A> >=A0=A0=A0 MEXT mailing list= =0A> >=A0=A0=A0 MEXT@ietf.org=0A> >=A0=A0=A0 https://www.ietf.org/mailman/l= istinfo/mext=0A> >=0A> >=0A> =0A> _________________________________________= ______=0A> MEXT mailing list=0A> MEXT@ietf.org=0A> https://www.ietf.org/mai= lman/listinfo/mext=0A=0A=0A=0A From wesley.m.eddy@nasa.gov Thu Jun 18 18:00:43 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67BC23A69A2 for ; Thu, 18 Jun 2009 18:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ZJlVrKc7gNZ2 for ; Thu, 18 Jun 2009 18:00:42 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 386A53A6960 for ; Thu, 18 Jun 2009 18:00:42 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 2BAE232818B; Thu, 18 Jun 2009 20:00:54 -0500 (CDT) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n5J10s8p013230; Thu, 18 Jun 2009 20:00:54 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Thu, 18 Jun 2009 20:00:54 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: Behcet Sarikaya Date: Thu, 18 Jun 2009 20:00:52 -0500 Thread-Topic: [MEXT] "buffer" action for flow binding Thread-Index: AcnwZg7FS0Kk1krERheP5wJ6JVM8ugADqUuC Message-ID: References: <000101c9efc0$c89161a0$110ca40a@china.huawei.com> <7ad6d6db0906180506u6193a66fh85ce4438f9ca8215@mail.gmail.com> , <786751.49101.qm@web111403.mail.gq1.yahoo.com> In-Reply-To: <786751.49101.qm@web111403.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-06-18_11:2009-06-01, 2009-06-18, 2009-06-18 signatures=0 Cc: "mext@ietf.org" Subject: Re: [MEXT] "buffer" action for flow binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 01:00:43 -0000 In general, it's enough to say that transports are robust to the temporary = network hiccups you throw at them, and this applies not only to TCP, but SC= TP, DCCP and other protocols as well. These all contain their own mechanis= ms for estimating path properties and responding to changes in the path. Y= es, there may be a small performance dip, but the connections will live on = and recover. Hopefully you aren't handing over too frequently anyways ... = and measurement data shows that many/most TCP connections are quite short (= only a few segments) since webpages are only a small number of kB in size, = on average. Sometimes the buffering under discussion may be helpful; we ca= n certainly tailor experiments and simulations that show that ... we can al= so tailor simulations and experiments to show that it's dangerous and can c= ause performance degradation instead of improvement under many conditions. = IP is assumed to be a best-effort service; no need to make it needlessly c= lever. Don't assume that the upper layers are so simple and fragile that they need= great amounts of help in order to perform, or you break them. There are m= any papers on how link-layer ARQ leading to high jitter and delay spikes in= jures end-to-end transport performance. RFC 3366 describes the danger in a= ssuming that high-persistence of the lower layers should be used in deliver= ing TCP segments and RFC 3481 documents a set of TCP extensions and tuning = parameters designed for robustness to links with handovers. There has also been an I-D discussed in TCPM several years ago about TCP-ba= sed response to connectivity changes if they are visible to the transport a= nd not masked/hidden by the network layer: http://tools.ietf.org/html/draft-schuetz-tcpm-tcp-rlci-03 The references in that I-D to [SHUETZ] and [EDDY] can be found on the web a= nd contain simulation results showing performance issues that occur when th= e network layer tries to hide path changes from the transport. ________________________________________ From: Behcet Sarikaya [behcetsarikaya@yahoo.com] Sent: Thursday, June 18, 2009 6:42 PM To: Eddy, Wesley M. (GRC-MS00)[Verizon] Cc: mext@ietf.org Subject: Re: [MEXT] "buffer" action for flow binding Hi Eddy, Thank you for your advice. However, I would like to know if you have any experimental data, research, = published papers, material to back it up. Please let us know. I know that T= CP behaviour in wireless links has been studied in depth but I for one am n= ot aware of any work on TCP and MIPv6 type of things, especially in this co= ntext. Regards, Behcet ----- Original Message ---- > From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" > To: Julien Laganier ; "w52006@huawei= .com" > Cc: "mext@ietf.org" > Sent: Thursday, June 18, 2009 12:15:32 PM > Subject: Re: [MEXT] "buffer" action for flow binding > > I wouldn't advise trying to do too much optimization on behalf > of TCP. It depends on the length of time to perform the > handover, but longish handovers can run near the RTO and the > data needing buffering during bulk-transfer is limited by the > ACKs already in-flight before handover due to the data segments > being clocked out by ACKs. For shorter handovers, TCP can > handle the loss detection and recovery efficiently through the > fast retransmission/recovery and SACK procedures. There is > also an argument some have made that TCP should be re- > initiating slow-start from its initial window after handovers > due to the fact that the path has completely changed and the > state established on the old path (cwnd, ssthresh, RTT, PMTU) > may be invalid. > > Just a bit of caution and skepticism that buffering at the HA > will work exactly as intended in all cases ... even in the > best case, the buffering will cause an RTT spike. > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > > > >-----Original Message----- > >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > >Julien Laganier > >Sent: Thursday, June 18, 2009 8:07 AM > >To: w52006@huawei.com > >Cc: mext@ietf.org > >Subject: Re: [MEXT] "buffer" action for flow binding > > > >Another potential usecase for buffering would be as follows: > > > >MN is receiving and/or sending bulk data transfer over TCP. Prior to > >handover it requests HA to buffer downlink packets. After Handover it > >requests HA to resume transmission of packets. In that way no TCP > >packets are lost because sent at the old MN CoA, and TCP transmission > >rate is less impacted or not impacted at all by the handover. > > > >--julien > > > > > >On Thu, Jun 18, 2009 at 4:59 AM, Yungui Wang wrote: > > > > > > Hello > > > > There is a scenario for the HA service provider. > > > > One MN is watching a real-time TV service from internet. For > > mobile IP service, > > a video flow is created on HA. At the time, a video call is > > incoming, the MN > > decides to response the call and pause the TV service. Due to > > lack of > > bandwidth he can't receive and buffer it locally. He may then ask > > the HA > > buffering the TV flow un-interruptted. Thus, new action "Buffer" > > may be > > needed for flow binding. > > > > 4 Buffer. This value indicates a request to buffer all packets > > in the flow described by the option. No BIDs are associated > > with > > this Action. > > > > Does it make sense? > > > > > > B.R. > > Yungui > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext= From hesham@elevatemobile.com Thu Jun 18 21:49:09 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342743A6A43 for ; Thu, 18 Jun 2009 21:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.774 X-Spam-Level: X-Spam-Status: No, score=-2.774 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 KKCO9IpMFfpc for ; Thu, 18 Jun 2009 21:49:08 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 15D533A6A34 for ; Thu, 18 Jun 2009 21:49:00 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MHGc7-0002x7-4S; Thu, 18 Jun 2009 22:21:07 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 18 Jun 2009 22:21:01 +1000 From: Hesham Soliman To: Julien Laganier , Message-ID: Thread-Topic: [MEXT] "buffer" action for flow binding Thread-Index: AcnwDz3fACs+VESSx0in0LrcA2wDSw== In-Reply-To: <7ad6d6db0906180506u6193a66fh85ce4438f9ca8215@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] "buffer" action for flow binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 04:49:09 -0000 Yes handover is a more likely case. Hesham On 18/06/09 10:06 PM, "Julien Laganier" wrote: > Another potential usecase for buffering would be as follows: > > MN is receiving and/or sending bulk data transfer over TCP. Prior to > handover it requests HA to buffer downlink packets. After Handover it > requests HA to resume transmission of packets. In that way no TCP packets > are lost because sent at the old MN CoA, and TCP transmission rate is less > impacted or not impacted at all by the handover. > > --julien > > On Thu, Jun 18, 2009 at 4:59 AM, Yungui Wang wrote: > >> Hello >> >> There is a scenario for the HA service provider. >> >> One MN is watching a real-time TV service from internet. For >> mobile IP service, >> a video flow is created on HA. At the time, a video call is >> incoming, the MN >> decides to response the call and pause the TV service. Due to >> lack of >> bandwidth he can't receive and buffer it locally. He may then ask >> the HA >> buffering the TV flow un-interruptted. Thus, new action "Buffer" >> may be >> needed for flow binding. >> >> 4 Buffer. This value indicates a request to buffer all packets >> in the flow described by the option. No BIDs are associated >> with >> this Action. >> >> Does it make sense? >> >> >> B.R. >> Yungui >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> From julien.laganier.ietf@googlemail.com Fri Jun 19 05:28:05 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8675D3A6879; Fri, 19 Jun 2009 05:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 HDgOD25-wnnu; Fri, 19 Jun 2009 05:28:04 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 901673A684D; Fri, 19 Jun 2009 05:28:03 -0700 (PDT) Received: by ewy6 with SMTP id 6so2496321ewy.37 for ; Fri, 19 Jun 2009 05:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:mime-version:content-type:message-id; bh=wsTr/0MJGeKt7laA6RA/x6b65uO3iNPhfzU+18PDW0I=; b=bY7epxKZxwttDHnez1iau8Yc9nziQkgeTC+xMhBF8Fmm1HN4zKDyhJ7RKWYZtwYjlm +5Vqo3tNH/gP7fI/PQ7jSowY5odW39F8x6PC7PhlD789lByHRX8VfHP1iBI9Nh0DO6TI 6oK9SneApW50NIy9ceASjBFaxQxkl/ZXbnUv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:mime-version:content-type :message-id; b=m2Uwhn8Wd05ZgJZhO3BmjK5VH3n6dFqzY0SJaGAnDLo2WmoU8Wu18GlA8GOZI/pkKC HL9K7LdEaWsTWvQi74shoOSIizYvEVhI2JXDk5mrsi9i4PiHScb1RRP0wCY6yLtPVOUF zv4d5y/czGMeFEOpP9OSLKliBNueJNCPhgnE0= Received: by 10.216.70.204 with SMTP id p54mr986661wed.87.1245414492242; Fri, 19 Jun 2009 05:28:12 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id t2sm7926524gve.15.2009.06.19.05.28.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Jun 2009 05:28:11 -0700 (PDT) From: Julien Laganier To: Jari Arkko Date: Fri, 19 Jun 2009 14:28:15 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_gR4OKl/yBtdN3aB" Message-Id: <200906191428.16595.julien.laganier.IETF@googlemail.com> Cc: netlmm@ietf.org, draft-ietf-mext-binding-revocation@tools.ietf.org, mext-chairs@tools.ietf.org, netlmm-chairs@tools.ietf.org, mext@ietf.org Subject: [MEXT] Request for publication of draft-ietf-mext-binding-revocation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 12:28:05 -0000 --Boundary-00=_gR4OKl/yBtdN3aB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Jari, Hereby the MEXT WG is requesting publication of "Binding Revocation for IPv6 Mobility" (draft-ietf-mext-binding-revocation-07) as a Proposed Standard RFC. The submission write-up is attached to this note. Thank you, --julien & marcelo, MEXT chairs. --Boundary-00=_gR4OKl/yBtdN3aB Content-Type: text/plain; charset="iso 8859-15"; name="BindingRevocationWriteUp.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="BindingRevocationWriteUp.txt" (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The Document Shepherd for this document is Julien Laganier, MEXT co-chair, who reviewed this version of the document and believes this version is ready for forwarding to the IESG. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, the document had review from both inside and outside the WG. In particular we had reviews from key members of the NETLMM WG, with which we coordinated progression of this documents. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The whole WG is behind this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? All of ID nits are passed but two that can be fixed with the next revision of the draft: - upgrade obsolete reference to RFC 2434 to RFC 5226. - use the new boilerplate with the disclaimer for pre-RFC5378 work. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Yes. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes (The document does not contain formal language). (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document is a product of the Mobility EXTensions for IPv6 (MEXT) working group and its progress was coordinated with the NETLMM WG. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The mechanism specified by this document is relied upon by the Evolved Packet System developed by 3GPP and as thus will be implemented by 3GPP vendors. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? The Document Shepherd for this document is Julien Laganier (MEXT WG co-chair). The Responsible Area Director is Jari Arkko (Internet Area Director). --Boundary-00=_gR4OKl/yBtdN3aB-- From behcetsarikaya@yahoo.com Fri Jun 19 08:04:35 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 185CB3A6828 for ; Fri, 19 Jun 2009 08:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 z8YpOfIjK07s for ; Fri, 19 Jun 2009 08:04:34 -0700 (PDT) Received: from n7.bullet.re3.yahoo.com (n7.bullet.re3.yahoo.com [68.142.237.92]) by core3.amsl.com (Postfix) with SMTP id B6C073A67A3 for ; Fri, 19 Jun 2009 08:04:33 -0700 (PDT) Received: from [68.142.230.28] by n7.bullet.re3.yahoo.com with NNFMP; 19 Jun 2009 15:04:44 -0000 Received: from [67.195.9.82] by t1.bullet.re2.yahoo.com with NNFMP; 19 Jun 2009 15:04:44 -0000 Received: from [67.195.9.108] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 19 Jun 2009 15:04:44 -0000 Received: from [127.0.0.1] by omp112.mail.gq1.yahoo.com with NNFMP; 19 Jun 2009 15:04:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 257169.32538.bm@omp112.mail.gq1.yahoo.com Received: (qmail 71676 invoked by uid 60001); 19 Jun 2009 15:04:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245423884; bh=HYOQLupAhRtCYQ0QxV0nge+fgf7nySxeGlb0BEXp42w=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2HNoF/FHAKadugFnMR6e0ff0ist2vXiyTc9UOf6uTPA8AI45ezgsvyHh/DFdUkaZBA8IKJKNpplvKMUrru8IGefu3z383EE1RdPfP0NmazXbQGk/qoa+OcJxM7tUmjXfq/cRvKVWAcgqKvh9Vof9Lterke7hH/Nk7591lMVLM5Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WPEZWcWpyQ2J+HfSUtEH2v0rCmP1B1qlS27xk5dVpvNkmoklxMOU5PYQy1lfAOM7kExv8sU+P95g1z7j3kVTlpOvJNRv95pYivaXSb7LhobYk7jEb6q60mc2Y86HHuTepTpSOqiSjDU6hfKad+XpEpLPf8K8atFB0gCWg9MOXhQ=; Message-ID: <98577.71611.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: pCJkohQVM1nnIgks2pBBNNcov7c488PlYd3muAXA79L6IS_3vFtRqz7qY84wBQ6q7yTGVpYvMN..3m_0Twff4UF8gWNXqjnrZ4.jOHpiRoJXrNJilBmo5Ne9Oh.9Y2.GfMhywv4gt6QQyE9Js36LaP6yYFqdmOuGisFAyQDk7xGFAlxmGNx5Iym4gbVNb60gJ9RPFfOWlaK_6dTC7vy9KrDQ6yke8dfG_6s4hIB5EpCsTllfPY4iaRKxKV5qKBMkzHbeiFoaPfePOVPQVdNzlGiZiNdAFap7SUsKypN_mWViAnsVrwrIJQM5jUovHqzb8pbG2ywMO7yGBtMcd9Ae9fuZdQ-- Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Fri, 19 Jun 2009 08:04:43 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 References: <000101c9efc0$c89161a0$110ca40a@china.huawei.com> <7ad6d6db0906180506u6193a66fh85ce4438f9ca8215@mail.gmail.com> , <786751.49101.qm@web111403.mail.gq1.yahoo.com> Date: Fri, 19 Jun 2009 08:04:43 -0700 (PDT) From: Behcet Sarikaya To: "Eddy, Wesley M. \(GRC-MS00\)\[Verizon\]" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mext@ietf.org" Subject: Re: [MEXT] "buffer" action for flow binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 15:04:35 -0000 Hi Eddy,=0A=A0 You are talking about pilc work (RFC 3366, etc.). Admittedly= one can show it either way.=0A=A0 The point here is that not all flows are= over TCP. In fact the example given was a video call which will probably b= e RTP flow. RTP does not control the transmission as much as TCP does. So b= uffering at a point like HA could be useful, this seems intuitively correct= .. =0A=A0 Do you have any objection to that?=0A=0ARegards,=0A=0ABehcet=0A=0A= =0A=0A----- Original Message ----=0A> From: "Eddy, Wesley M. (GRC-MS00)[Ver= izon]" =0A> To: Behcet Sarikaya = =0A> Cc: "mext@ietf.org" =0A> Sent: Thursday, June 18, 2009 = 8:00:52 PM=0A> Subject: RE: [MEXT] "buffer" action for flow binding=0A> =0A= > In general, it's enough to say that transports are robust to the temporar= y =0A> network hiccups you throw at them, and this applies not only to TCP,= but SCTP, =0A> DCCP and other protocols as well.=A0 These all contain thei= r own mechanisms for =0A> estimating path properties and responding to chan= ges in the path.=A0 Yes, there =0A> may be a small performance dip, but the= connections will live on and recover.=A0 =0A> Hopefully you aren't handing= over too frequently anyways ... and measurement =0A> data shows that many/= most TCP connections are quite short (only a few segments) =0A> since webpa= ges are only a small number of kB in size, on average.=A0 Sometimes the =0A= > buffering under discussion may be helpful; we can certainly tailor experi= ments =0A> and simulations that show that ... we can also tailor simulation= s and =0A> experiments to show that it's dangerous and can cause performanc= e degradation =0A> instead of improvement under many conditions.=A0 IP is a= ssumed to be a best-effort =0A> service; no need to make it needlessly clev= er.=0A> =0A> Don't assume that the upper layers are so simple and fragile t= hat they need =0A> great amounts of help in order to perform, or you break = them.=A0 There are many =0A> papers on how link-layer ARQ leading to high j= itter and delay spikes injures =0A> end-to-end transport performance.=A0 RF= C 3366 describes the danger in assuming =0A> that high-persistence of the l= ower layers should be used in delivering TCP =0A> segments and RFC 3481 doc= uments a set of TCP extensions and tuning parameters =0A> designed for robu= stness to links with handovers.=0A> =0A> There has also been an I-D discuss= ed in TCPM several years ago about TCP-based =0A> response to connectivity = changes if they are visible to the transport and not =0A> masked/hidden by = the network layer:=0A> http://tools.ietf.org/html/draft-schuetz-tcpm-tcp-rl= ci-03=0A> The references in that I-D to [SHUETZ] and [EDDY] can be found on= the web and =0A> contain simulation results showing performance issues tha= t occur when the =0A> network layer tries to hide path changes from the tra= nsport.=0A> =0A> =0A> ________________________________________=0A> From: Be= hcet Sarikaya [behcetsarikaya@yahoo.com]=0A> Sent: Thursday, June 18, 2009 = 6:42 PM=0A> To: Eddy, Wesley M. (GRC-MS00)[Verizon]=0A> Cc: mext@ietf.org= =0A> Subject: Re: [MEXT] "buffer" action for flow binding=0A> =0A> Hi Eddy,= =0A> =A0 Thank you for your advice.=0A> However, I would like to know if yo= u have any experimental data, research, =0A> published papers, material to = back it up. Please let us know. I know that TCP =0A> behaviour in wireless = links has been studied in depth but I for one am not aware =0A> of any work= on TCP and MIPv6 type of things, especially in this context.=0A> =0A> Rega= rds,=0A> =0A> Behcet=0A> =0A> =0A> =0A> ----- Original Message ----=0A> > F= rom: "Eddy, Wesley M. (GRC-MS00)[Verizon]" =0A> > To: Julien Laganier ; "w5= 2006@huawei.com" =0A> =0A> > Cc: "mext@ietf.org" =0A> > Sent: Thursday, Jun= e 18, 2009 12:15:32 PM=0A> > Subject: Re: [MEXT] "buffer" action for flow b= inding=0A> >=0A> > I wouldn't advise trying to do too much optimization on = behalf=0A> > of TCP.=A0 It depends on the length of time to perform the=0A>= > handover, but longish handovers can run near the RTO and the=0A> > data = needing buffering during bulk-transfer is limited by the=0A> > ACKs already= in-flight before handover due to the data segments=0A> > being clocked out= by ACKs.=A0 For shorter handovers, TCP can=0A> > handle the loss detection= and recovery efficiently through the=0A> > fast retransmission/recovery an= d SACK procedures.=A0 There is=0A> > also an argument some have made that T= CP should be re-=0A> > initiating slow-start from its initial window after = handovers=0A> > due to the fact that the path has completely changed and th= e=0A> > state established on the old path (cwnd, ssthresh, RTT, PMTU)=0A> >= may be invalid.=0A> >=0A> > Just a bit of caution and skepticism that buff= ering at the HA=0A> > will work exactly as intended in all cases ... even i= n the=0A> > best case, the buffering will cause an RTT spike.=0A> >=0A> > -= --------------------------=0A> > Wes Eddy=0A> > Network & Systems Architect= =0A> > Verizon FNS / NASA GRC=0A> > Office: (216) 433-6682=0A> > ----------= -----------------=0A> >=0A> >=0A> > >-----Original Message-----=0A> > >From= : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of=0A> > >= Julien Laganier=0A> > >Sent: Thursday, June 18, 2009 8:07 AM=0A> > >To: w52= 006@huawei.com=0A> > >Cc: mext@ietf.org=0A> > >Subject: Re: [MEXT] "buffer"= action for flow binding=0A> > >=0A> > >Another potential usecase for buffe= ring would be as follows:=0A> > >=0A> > >MN is receiving and/or sending bul= k data transfer over TCP. Prior to=0A> > >handover it requests HA to buffer= downlink packets. After Handover it=0A> > >requests HA to resume transmiss= ion of packets. In that way no TCP=0A> > >packets are lost because sent at = the old MN CoA, and TCP transmission=0A> > >rate is less impacted or not im= pacted at all by the handover.=0A> > >=0A> > >--julien=0A> > >=0A> > >=0A> = > >On Thu, Jun 18, 2009 at 4:59 AM, Yungui Wang wrote:=0A> > >=0A> > >=0A> = > >=A0 =A0 Hello=0A> > >=0A> > >=A0 =A0 There is a scenario for the HA serv= ice provider.=0A> > >=0A> > >=A0 =A0 One MN is watching a real-time TV serv= ice from internet. For=0A> > >=A0 =A0 mobile IP service,=0A> > >=A0 =A0 a v= ideo flow is created on HA. At the time, a video call is=0A> > >=A0 =A0 inc= oming, the MN=0A> > >=A0 =A0 decides to response the call and pause the TV = service.=A0 Due to=0A> > >=A0 =A0 lack of=0A> > >=A0 =A0 bandwidth he can't= receive and buffer it locally. He may then ask=0A> > >=A0 =A0 the HA=0A> >= >=A0 =A0 buffering the TV flow un-interruptted. Thus, new action "Buffer"= =0A> > >=A0 =A0 may be=0A> > >=A0 =A0 needed for flow binding.=0A> > >=0A> = > >=A0 =A0 4 Buffer.=A0 This value indicates a request to buffer all packet= s=0A> > >=A0 =A0 =A0 =A0 in the flow described by the option.=A0 No BIDs ar= e associated=0A> > >=A0 =A0 with=0A> > >=A0 =A0 =A0 =A0 this Action.=0A> > = >=0A> > >=A0 =A0 Does it make sense?=0A> > >=0A> > >=0A> > >=A0 =A0 B.R.=0A= > > >=A0 =A0 Yungui=0A> > >=0A> > >=0A> > >=A0 =A0 ________________________= _______________________=0A> > >=A0 =A0 MEXT mailing list=0A> > >=A0 =A0 MEX= T@ietf.org=0A> > >=A0 =A0 https://www.ietf.org/mailman/listinfo/mext=0A> > = >=0A> > >=0A> >=0A> > _______________________________________________=0A> >= MEXT mailing list=0A> > MEXT@ietf.org=0A> > https://www.ietf.org/mailman/l= istinfo/mext=0A=0A=0A=0A From wesley.m.eddy@nasa.gov Fri Jun 19 09:57:10 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C48A3A6A75 for ; Fri, 19 Jun 2009 09:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 mU-wq6+DX+iV for ; Fri, 19 Jun 2009 09:57:09 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id 20F093A699C for ; Fri, 19 Jun 2009 09:57:08 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 1B3D7A8781; Fri, 19 Jun 2009 11:57:22 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03.ndc.nasa.gov [198.117.4.162]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n5JGvMX8020618; Fri, 19 Jun 2009 11:57:22 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Fri, 19 Jun 2009 11:57:22 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: Behcet Sarikaya Date: Fri, 19 Jun 2009 11:57:20 -0500 Thread-Topic: [MEXT] "buffer" action for flow binding Thread-Index: Acnw70i8LOXaXYxpTP6WFfdMp1IkhQADWyIw Message-ID: References: <000101c9efc0$c89161a0$110ca40a@china.huawei.com> <7ad6d6db0906180506u6193a66fh85ce4438f9ca8215@mail.gmail.com> , <786751.49101.qm@web111403.mail.gq1.yahoo.com> <98577.71611.qm@web111413.mail.gq1.yahoo.com> In-Reply-To: <98577.71611.qm@web111413.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-06-19_02:2009-06-01, 2009-06-19, 2009-06-18 signatures=0 Cc: "mext@ietf.org" Subject: Re: [MEXT] "buffer" action for flow binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 16:57:10 -0000 Yes, even for RTP it's very naive to assume that buffering in the HA is productive, and even for RTP it can be counterproductive. If the end host player uses short buffers to bound delay in the application interactivity, the data you buffer in the HA will likely be below the playback pointer by the time it arrives, and simply be discarded. You'll also be wasting time and bandwidth transmitting this stale data across a possibly constrained link only to have to tossed away by the application. There are certainly thresholds where HA buffering could be useful to an A/V codec, but the time limits are quite heavily dependent on the specific application software and its local configuration which vary widely in the wild. The limited potential for good results combined with the definite possibility of bad results, and the inherent additional complexity make this a non-starter in my mind. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- >-----Original Message----- >From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] >Sent: Friday, June 19, 2009 11:05 AM >To: Eddy, Wesley M. (GRC-MS00)[Verizon] >Cc: mext@ietf.org >Subject: Re: [MEXT] "buffer" action for flow binding > > >Hi Eddy, >=A0 You are talking about pilc work (RFC 3366, etc.). Admittedly one can >show it either way. >=A0 The point here is that not all flows are over TCP. In fact the example >given was a video call which will probably be RTP flow. RTP does not >control the transmission as much as TCP does. So buffering at a point >like HA could be useful, this seems intuitively correct.. >=A0 Do you have any objection to that? > >Regards, > >Behcet > > > >----- Original Message ---- >> From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" >> To: Behcet Sarikaya >> Cc: "mext@ietf.org" >> Sent: Thursday, June 18, 2009 8:00:52 PM >> Subject: RE: [MEXT] "buffer" action for flow binding >> >> In general, it's enough to say that transports are robust to the >temporary >> network hiccups you throw at them, and this applies not only to TCP, >but SCTP, >> DCCP and other protocols as well.=A0 These all contain their own >mechanisms for >> estimating path properties and responding to changes in the path. >Yes, there >> may be a small performance dip, but the connections will live on and >recover. >> Hopefully you aren't handing over too frequently anyways ... and >measurement >> data shows that many/most TCP connections are quite short (only a few >segments) >> since webpages are only a small number of kB in size, on average. >Sometimes the >> buffering under discussion may be helpful; we can certainly tailor >experiments >> and simulations that show that ... we can also tailor simulations and >> experiments to show that it's dangerous and can cause performance >degradation >> instead of improvement under many conditions.=A0 IP is assumed to be a >best-effort >> service; no need to make it needlessly clever. >> >> Don't assume that the upper layers are so simple and fragile that they >need >> great amounts of help in order to perform, or you break them.=A0 There >are many >> papers on how link-layer ARQ leading to high jitter and delay spikes >injures >> end-to-end transport performance.=A0 RFC 3366 describes the danger in >assuming >> that high-persistence of the lower layers should be used in delivering >TCP >> segments and RFC 3481 documents a set of TCP extensions and tuning >parameters >> designed for robustness to links with handovers. >> >> There has also been an I-D discussed in TCPM several years ago about >TCP-based >> response to connectivity changes if they are visible to the transport >and not >> masked/hidden by the network layer: >> http://tools.ietf.org/html/draft-schuetz-tcpm-tcp-rlci-03 >> The references in that I-D to [SHUETZ] and [EDDY] can be found on the >web and >> contain simulation results showing performance issues that occur when >the >> network layer tries to hide path changes from the transport. >> >> >> ________________________________________ >> From: Behcet Sarikaya [behcetsarikaya@yahoo.com] >> Sent: Thursday, June 18, 2009 6:42 PM >> To: Eddy, Wesley M. (GRC-MS00)[Verizon] >> Cc: mext@ietf.org >> Subject: Re: [MEXT] "buffer" action for flow binding >> >> Hi Eddy, >> =A0 Thank you for your advice. >> However, I would like to know if you have any experimental data, >research, >> published papers, material to back it up. Please let us know. I know >that TCP >> behaviour in wireless links has been studied in depth but I for one am >not aware >> of any work on TCP and MIPv6 type of things, especially in this >context. >> >> Regards, >> >> Behcet >> >> >> >> ----- Original Message ---- >> > From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" >> > To: Julien Laganier ; "w52006@huawei.com" >> >> > Cc: "mext@ietf.org" >> > Sent: Thursday, June 18, 2009 12:15:32 PM >> > Subject: Re: [MEXT] "buffer" action for flow binding >> > >> > I wouldn't advise trying to do too much optimization on behalf >> > of TCP.=A0 It depends on the length of time to perform the >> > handover, but longish handovers can run near the RTO and the >> > data needing buffering during bulk-transfer is limited by the >> > ACKs already in-flight before handover due to the data segments >> > being clocked out by ACKs.=A0 For shorter handovers, TCP can >> > handle the loss detection and recovery efficiently through the >> > fast retransmission/recovery and SACK procedures.=A0 There is >> > also an argument some have made that TCP should be re- >> > initiating slow-start from its initial window after handovers >> > due to the fact that the path has completely changed and the >> > state established on the old path (cwnd, ssthresh, RTT, PMTU) >> > may be invalid. >> > >> > Just a bit of caution and skepticism that buffering at the HA >> > will work exactly as intended in all cases ... even in the >> > best case, the buffering will cause an RTT spike. >> > >> > --------------------------- >> > Wes Eddy >> > Network & Systems Architect >> > Verizon FNS / NASA GRC >> > Office: (216) 433-6682 >> > --------------------------- >> > >> > >> > >-----Original Message----- >> > >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >Behalf Of >> > >Julien Laganier >> > >Sent: Thursday, June 18, 2009 8:07 AM >> > >To: w52006@huawei.com >> > >Cc: mext@ietf.org >> > >Subject: Re: [MEXT] "buffer" action for flow binding >> > > >> > >Another potential usecase for buffering would be as follows: >> > > >> > >MN is receiving and/or sending bulk data transfer over TCP. Prior >to >> > >handover it requests HA to buffer downlink packets. After Handover >it >> > >requests HA to resume transmission of packets. In that way no TCP >> > >packets are lost because sent at the old MN CoA, and TCP >transmission >> > >rate is less impacted or not impacted at all by the handover. >> > > >> > >--julien >> > > >> > > >> > >On Thu, Jun 18, 2009 at 4:59 AM, Yungui Wang wrote: >> > > >> > > >> > >=A0 =A0 Hello >> > > >> > >=A0 =A0 There is a scenario for the HA service provider. >> > > >> > >=A0 =A0 One MN is watching a real-time TV service from internet. For >> > >=A0 =A0 mobile IP service, >> > >=A0 =A0 a video flow is created on HA. At the time, a video call is >> > >=A0 =A0 incoming, the MN >> > >=A0 =A0 decides to response the call and pause the TV service.=A0 Due= to >> > >=A0 =A0 lack of >> > >=A0 =A0 bandwidth he can't receive and buffer it locally. He may then >ask >> > >=A0 =A0 the HA >> > >=A0 =A0 buffering the TV flow un-interruptted. Thus, new action >"Buffer" >> > >=A0 =A0 may be >> > >=A0 =A0 needed for flow binding. >> > > >> > >=A0 =A0 4 Buffer.=A0 This value indicates a request to buffer all pac= kets >> > >=A0 =A0 =A0 =A0 in the flow described by the option.=A0 No BIDs are >associated >> > >=A0 =A0 with >> > >=A0 =A0 =A0 =A0 this Action. >> > > >> > >=A0 =A0 Does it make sense? >> > > >> > > >> > >=A0 =A0 B.R. >> > >=A0 =A0 Yungui >> > > >> > > >> > >=A0 =A0 _______________________________________________ >> > >=A0 =A0 MEXT mailing list >> > >=A0 =A0 MEXT@ietf.org >> > >=A0 =A0 https://www.ietf.org/mailman/listinfo/mext >> > > >> > > >> > >> > _______________________________________________ >> > MEXT mailing list >> > MEXT@ietf.org >> > https://www.ietf.org/mailman/listinfo/mext > > > > From marcelo@it.uc3m.es Sat Jun 20 06:21:52 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A304728C14B for ; Sat, 20 Jun 2009 06:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.621 X-Spam-Level: X-Spam-Status: No, score=-6.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vqUrpTGkr+ls for ; Sat, 20 Jun 2009 06:21:52 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id C931628C144 for ; Sat, 20 Jun 2009 06:21:51 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (131.pool85-53-139.dynamic.orange.es [85.53.139.131]) by smtp03.uc3m.es (Postfix) with ESMTP id B9520731736; Sat, 20 Jun 2009 15:22:03 +0200 (CEST) Message-ID: <4A3CE27B.4020108@it.uc3m.es> Date: Sat, 20 Jun 2009 15:22:03 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16714.007 Cc: Julien Laganier Subject: [MEXT] Presentations for IETF75 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2009 13:21:52 -0000 If someone want to make a presentation at IETF75, please let us know ASAP. Regards, marcelo From marcelo@it.uc3m.es Sun Jun 21 02:58:46 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C1E93A6BF1 for ; Sun, 21 Jun 2009 02:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.62 X-Spam-Level: X-Spam-Status: No, score=-6.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 2MtSmtu1UMk2 for ; Sun, 21 Jun 2009 02:58:45 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id E60443A6B57 for ; Sun, 21 Jun 2009 02:58:43 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (131.pool85-53-139.dynamic.orange.es [85.53.139.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 62C956BACAB for ; Sun, 21 Jun 2009 11:58:55 +0200 (CEST) Message-ID: <4A3E045F.2050605@it.uc3m.es> Date: Sun, 21 Jun 2009 11:58:55 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16716.006 Subject: [MEXT] early vs. late flow bindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 09:58:46 -0000 Hi, I would like to make a comment on the flow binding approaches. First of all, i think it is important for this comment to clarify what is the minimum flow granularity we would like to support. I personally believe that the _minimum_ unit of flow that we would like to specify that it needs to be forwarded through a given CoA can be expressed either as: - src add, dst add, protocol, src port, dst port, or - src add, dst add, SPI So, do people think that we need to support higher granularity than this? I.e. that we need to send some packets of a TCP connection through one CoA and other packets of the same TCP connection through a different CoA? So, for the rest of the argument, I will assume that with this granularity suffices . So, when we want to bind a flow to a give CoA, we can do an early binding or a late binging. Let me explain what i mean by that (in case it not obvious from the wonderfully intuitive terminology i selected) A late binding would work as follows. The MN has a default CoA through which it receives all flows that have no binding. When the MN starts receiving a flow and the MN internal policy states that this particular flow should flow through an alternative CoA, it sends a flow binding message, saying that _this_ particular flow (identified either by the 5-tuple (src add, dest add, src port, dest port, protocol) or by the 3-tuple (src add, dst add, SPI)) is bound to an alternative CoA. When the HA receives this msg, it moves the flow to the right CoA. An early binding is when the MN notifies the HA about what are the flow descriptors of flows that should be forwarded though each CoA. So, for instance the MN sends a flow binding saying that all packets addressed to port TCP 80 (irrespectively of the src and dst address) should be forwarded to a given CoA. So, whenever a packet arrives for port 80, it is directly forwarded to the selected CoA. Now, the disadvantage of the late binding is that it requires sending a flow binding msg per new flow (so it is more overhead) and it is reactive, so the first packets of the flow would flow through the default CoA. the advantage of early bindings is that we don't really need to encode in the flow descriptors all kind of transport and application fields that describe a flow. So, due to the aforementioned disadvantages of the early bindings, i don't think it is optimal to only use early bindings (even though it would be the cleaner approach imho). However, imho we can certainly use the late bindings for those flows that require more sophisticated flow descriptors. So, imho, we should support the IP packet fields and the protocol, src port and dst port as flow descriptors to be used in early bindings and let all the rest of the flows that cannot be properly described with these fields to be handled with late bindings. comments? Regards, marcelo From w52006@huawei.com Sun Jun 21 19:03:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89D0928C189 for ; Sun, 21 Jun 2009 19:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.261 X-Spam-Level: X-Spam-Status: No, score=-0.261 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 mAXahQIoLULy for ; Sun, 21 Jun 2009 19:03:12 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 097B428C108 for ; Sun, 21 Jun 2009 19:03:12 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLM00LNFB1G17@szxga04-in.huawei.com> for mext@ietf.org; Mon, 22 Jun 2009 10:03:16 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLM00CKNB1GD6@szxga04-in.huawei.com> for mext@ietf.org; Mon, 22 Jun 2009 10:03:16 +0800 (CST) Received: from w52006d ([10.164.12.17]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLM0000OB1FKH@szxml06-in.huawei.com> for mext@ietf.org; Mon, 22 Jun 2009 10:03:16 +0800 (CST) Date: Mon, 22 Jun 2009 10:03:15 +0800 From: Yungui Wang In-reply-to: To: "'Eddy, Wesley M. (GRC-MS00)[Verizon]'" , 'Behcet Sarikaya' , 'Yuri Ismailov' Message-id: <002f01c9f2dd$9b186050$110ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: Acnw70i8LOXaXYxpTP6WFfdMp1IkhQADWyIwAHaVOiA= Cc: mext@ietf.org Subject: Re: [MEXT] "buffer" action for flow binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 02:03:13 -0000 Hello Thanks for your clarification.=20 My intent is an enhanced HA in which a ALG or backend server may be=20 located as Yuri said could do more things. More conveniently, DPI-like=20 technology (L3~L7) is more and more popular. I don't think it is very=20 difficult to be done. Here, what we need is a simple request from MN.=20 However, I am also not sure if the IP-layer request is appropriate. But, as I know, there is a similar example that a server located=20 in/side of a router (even side of AN) may buffer the multicast stream=20 (a TV channel or the important frames of a channel) for fast channel=20 switch in the fixed network. While, when a user sends a IP-layer=20 request (IGMP) for a new channel, the router (/server) may firstly push the buffered channel to the user, then do further works. B.R. Yungui > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of Eddy, Wesley M. (GRC-MS00)[Verizon] > Sent: Saturday, June 20, 2009 12:57 AM > To: Behcet Sarikaya > Cc: mext@ietf.org > Subject: Re: [MEXT] "buffer" action for flow binding >=20 > Yes, even for RTP it's very naive to assume that buffering in=20 > the HA is productive, and even for RTP it can be counterproductive. > If the end host player uses short buffers to bound delay in=20 > the application interactivity, the data you buffer in the HA=20 > will likely be below the playback pointer by the time it=20 > arrives, and simply be discarded. You'll also be wasting=20 > time and bandwidth transmitting this stale data across a=20 > possibly constrained link only to have to tossed away by the=20 > application. There are certainly thresholds where HA=20 > buffering could be useful to an A/V codec, but the time=20 > limits are quite heavily dependent on the specific=20 > application software and its local configuration which vary=20 > widely in the wild. The limited potential for good results=20 > combined with the definite possibility of bad results, and=20 > the inherent additional complexity make this a non-starter in my mind. >=20 > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- >=20 > >-----Original Message----- > >From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > >Sent: Friday, June 19, 2009 11:05 AM > >To: Eddy, Wesley M. (GRC-MS00)[Verizon] > >Cc: mext@ietf.org > >Subject: Re: [MEXT] "buffer" action for flow binding > > > > > >Hi Eddy, > >=A0 You are talking about pilc work (RFC 3366, etc.).=20 > Admittedly one can=20 > >show it either way. > >=A0 The point here is that not all flows are over TCP. In fact the=20 > >example given was a video call which will probably be RTP flow. RTP=20 > >does not control the transmission as much as TCP does. So=20 > buffering at=20 > >a point like HA could be useful, this seems intuitively correct.. > >=A0 Do you have any objection to that? > > > >Regards, > > > >Behcet > > > > > > > >----- Original Message ---- > >> From: "Eddy, Wesley M. (GRC-MS00)[Verizon]"=20 > > >> To: Behcet Sarikaya > >> Cc: "mext@ietf.org" > >> Sent: Thursday, June 18, 2009 8:00:52 PM > >> Subject: RE: [MEXT] "buffer" action for flow binding > >> > >> In general, it's enough to say that transports are robust to the > >temporary > >> network hiccups you throw at them, and this applies not=20 > only to TCP, > >but SCTP, > >> DCCP and other protocols as well.=A0 These all contain their own > >mechanisms for > >> estimating path properties and responding to changes in the path. > >Yes, there > >> may be a small performance dip, but the connections will=20 > live on and > >recover. > >> Hopefully you aren't handing over too frequently anyways ... and > >measurement > >> data shows that many/most TCP connections are quite short=20 > (only a few > >segments) > >> since webpages are only a small number of kB in size, on average. > >Sometimes the > >> buffering under discussion may be helpful; we can certainly tailor > >experiments > >> and simulations that show that ... we can also tailor=20 > simulations and=20 > >> experiments to show that it's dangerous and can cause performance > >degradation > >> instead of improvement under many conditions.=A0 IP is=20 > assumed to be a > >best-effort > >> service; no need to make it needlessly clever. > >> > >> Don't assume that the upper layers are so simple and fragile that=20 > >> they > >need > >> great amounts of help in order to perform, or you break=20 > them.=A0 There > >are many > >> papers on how link-layer ARQ leading to high jitter and=20 > delay spikes > >injures > >> end-to-end transport performance.=A0 RFC 3366 describes the danger in > >assuming > >> that high-persistence of the lower layers should be used in=20 > >> delivering > >TCP > >> segments and RFC 3481 documents a set of TCP extensions and tuning > >parameters > >> designed for robustness to links with handovers. > >> > >> There has also been an I-D discussed in TCPM several years=20 > ago about > >TCP-based > >> response to connectivity changes if they are visible to=20 > the transport > >and not > >> masked/hidden by the network layer: > >> http://tools.ietf.org/html/draft-schuetz-tcpm-tcp-rlci-03 > >> The references in that I-D to [SHUETZ] and [EDDY] can be=20 > found on the > >web and > >> contain simulation results showing performance issues that=20 > occur when > >the > >> network layer tries to hide path changes from the transport. > >> > >> > >> ________________________________________ > >> From: Behcet Sarikaya [behcetsarikaya@yahoo.com] > >> Sent: Thursday, June 18, 2009 6:42 PM > >> To: Eddy, Wesley M. (GRC-MS00)[Verizon] > >> Cc: mext@ietf.org > >> Subject: Re: [MEXT] "buffer" action for flow binding > >> > >> Hi Eddy, > >> =A0 Thank you for your advice. > >> However, I would like to know if you have any experimental data, > >research, > >> published papers, material to back it up. Please let us=20 > know. I know > >that TCP > >> behaviour in wireless links has been studied in depth but=20 > I for one=20 > >> am > >not aware > >> of any work on TCP and MIPv6 type of things, especially in this > >context. > >> > >> Regards, > >> > >> Behcet > >> > >> > >> > >> ----- Original Message ---- > >> > From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" > >> > To: Julien Laganier ; "w52006@huawei.com" > >> > >> > Cc: "mext@ietf.org" > >> > Sent: Thursday, June 18, 2009 12:15:32 PM > >> > Subject: Re: [MEXT] "buffer" action for flow binding > >> > > >> > I wouldn't advise trying to do too much optimization on=20 > behalf of=20 > >> > TCP.=A0 It depends on the length of time to perform the=20 > handover, but=20 > >> > longish handovers can run near the RTO and the data needing > >> > buffering during bulk-transfer is limited by the ACKs already=20 > >> > in-flight before handover due to the data segments being clocked=20 > >> > out by ACKs.=A0 For shorter handovers, TCP can handle the loss=20 > >> > detection and recovery efficiently through the fast=20 > >> > retransmission/recovery and SACK procedures.=A0 There is also an=20 > >> > argument some have made that TCP should be re- initiating=20 > >> > slow-start from its initial window after handovers due=20 > to the fact=20 > >> > that the path has completely changed and the state=20 > established on=20 > >> > the old path (cwnd, ssthresh, RTT, PMTU) may be invalid. > >> > > >> > Just a bit of caution and skepticism that buffering at=20 > the HA will=20 > >> > work exactly as intended in all cases ... even in the best case,=20 > >> > the buffering will cause an RTT spike. > >> > > >> > --------------------------- > >> > Wes Eddy > >> > Network & Systems Architect > >> > Verizon FNS / NASA GRC > >> > Office: (216) 433-6682 > >> > --------------------------- > >> > > >> > > >> > >-----Original Message----- > >> > >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > >Behalf Of > >> > >Julien Laganier > >> > >Sent: Thursday, June 18, 2009 8:07 AM > >> > >To: w52006@huawei.com > >> > >Cc: mext@ietf.org > >> > >Subject: Re: [MEXT] "buffer" action for flow binding > >> > > > >> > >Another potential usecase for buffering would be as follows: > >> > > > >> > >MN is receiving and/or sending bulk data transfer over=20 > TCP. Prior > >to > >> > >handover it requests HA to buffer downlink packets.=20 > After Handover > >it > >> > >requests HA to resume transmission of packets. In that=20 > way no TCP=20 > >> > >packets are lost because sent at the old MN CoA, and TCP > >transmission > >> > >rate is less impacted or not impacted at all by the handover. > >> > > > >> > >--julien > >> > > > >> > > > >> > >On Thu, Jun 18, 2009 at 4:59 AM, Yungui Wang wrote: > >> > > > >> > > > >> > >=A0 =A0 Hello > >> > > > >> > >=A0 =A0 There is a scenario for the HA service provider. > >> > > > >> > >=A0 =A0 One MN is watching a real-time TV service from internet. For > >> > >=A0 =A0 mobile IP service, > >> > >=A0 =A0 a video flow is created on HA. At the time, a video call is > >> > >=A0 =A0 incoming, the MN > >> > >=A0 =A0 decides to response the call and pause the TV=20 > service.=A0 Due to > >> > >=A0 =A0 lack of > >> > >=A0 =A0 bandwidth he can't receive and buffer it locally.=20 > He may then > >ask > >> > >=A0 =A0 the HA > >> > >=A0 =A0 buffering the TV flow un-interruptted. Thus, new action > >"Buffer" > >> > >=A0 =A0 may be > >> > >=A0 =A0 needed for flow binding. > >> > > > >> > >=A0 =A0 4 Buffer.=A0 This value indicates a request to buffer all=20 > >> > >packets > >> > >=A0 =A0 =A0 =A0 in the flow described by the option.=A0 No BIDs = are > >associated > >> > >=A0 =A0 with > >> > >=A0 =A0 =A0 =A0 this Action. > >> > > > >> > >=A0 =A0 Does it make sense? > >> > > > >> > > > >> > >=A0 =A0 B.R. > >> > >=A0 =A0 Yungui > >> > > > >> > > > >> > >=A0 =A0 _______________________________________________ > >> > >=A0 =A0 MEXT mailing list > >> > >=A0 =A0 MEXT@ietf.org > >> > >=A0 =A0 https://www.ietf.org/mailman/listinfo/mext > >> > > > >> > > > >> > > >> > _______________________________________________ > >> > MEXT mailing list > >> > MEXT@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 From w52006@huawei.com Sun Jun 21 20:18:06 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A1673A68F3 for ; Sun, 21 Jun 2009 20:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 QsSEgMgOOtOE for ; Sun, 21 Jun 2009 20:18:05 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5D39C3A68E7 for ; Sun, 21 Jun 2009 20:18:05 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLM0093LEEXNK@szxga04-in.huawei.com> for mext@ietf.org; Mon, 22 Jun 2009 11:16:10 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLM00FQ8EEXN7@szxga04-in.huawei.com> for mext@ietf.org; Mon, 22 Jun 2009 11:16:09 +0800 (CST) Received: from w52006d ([10.164.12.17]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLM00LI5EEXE8@szxml06-in.huawei.com> for mext@ietf.org; Mon, 22 Jun 2009 11:16:09 +0800 (CST) Date: Mon, 22 Jun 2009 11:16:09 +0800 From: Yungui Wang In-reply-to: <4A3E045F.2050605@it.uc3m.es> To: 'marcelo bagnulo braun' , 'mext' Message-id: <003001c9f2e7$c9fba850$110ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnyV2zoUFsRmESCQc+Y6fDkrzrp2wAjkC1g Subject: Re: [MEXT] early vs. late flow bindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 03:18:06 -0000 Hello Do we need to differentiate whether a binding is the early binding or the late binding? It seems implementation-specific. B.R. Yungui > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of marcelo bagnulo braun > Sent: Sunday, June 21, 2009 5:59 PM > To: mext > Subject: [MEXT] early vs. late flow bindings > > Hi, > > I would like to make a comment on the flow binding approaches. > > First of all, i think it is important for this comment to > clarify what is the minimum flow granularity we would like to support. > I personally believe that the _minimum_ unit of flow that we > would like to specify that it needs to be forwarded through a > given CoA can be expressed either as: > - src add, dst add, protocol, src port, dst port, or > - src add, dst add, SPI > > So, do people think that we need to support higher > granularity than this? I.e. that we need to send some packets > of a TCP connection through one CoA and other packets of the > same TCP connection through a different CoA? > > So, for the rest of the argument, I will assume that with > this granularity suffices . > So, when we want to bind a flow to a give CoA, we can do an > early binding or a late binging. Let me explain what i mean > by that (in case it not obvious from the wonderfully > intuitive terminology i selected) > > A late binding would work as follows. The MN has a default > CoA through which it receives all flows that have no binding. > When the MN starts receiving a flow and the MN internal > policy states that this particular flow should flow through > an alternative CoA, it sends a flow binding message, saying > that _this_ particular flow (identified either by the 5-tuple > (src add, dest add, src port, dest port, protocol) or by the > 3-tuple (src add, dst add, SPI)) is bound to an alternative > CoA. When the HA receives this msg, it moves the flow to the > right CoA. > > An early binding is when the MN notifies the HA about what > are the flow descriptors of flows that should be forwarded > though each CoA. So, for instance the MN sends a flow binding > saying that all packets addressed to port TCP 80 > (irrespectively of the src and dst address) should be > forwarded to a given CoA. So, whenever a packet arrives for > port 80, it is directly forwarded to the selected CoA. > > Now, the disadvantage of the late binding is that it requires > sending a flow binding msg per new flow (so it is more > overhead) and it is reactive, so the first packets of the > flow would flow through the default CoA. the advantage of > early bindings is that we don't really need to encode in the > flow descriptors all kind of transport and application fields > that describe a flow. > > So, due to the aforementioned disadvantages of the early > bindings, i don't think it is optimal to only use early > bindings (even though it would be the cleaner approach imho). > However, imho we can certainly use the late bindings for > those flows that require more sophisticated flow descriptors. > So, imho, we should support the IP packet fields and the > protocol, src port and dst port as flow descriptors to be > used in early bindings and let all the rest of the flows that > cannot be properly described with these fields to be handled > with late bindings. > > comments? > > Regards, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From xiajinwei@huawei.com Sun Jun 21 23:45:09 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C743A68B4 for ; Sun, 21 Jun 2009 23:45:09 -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=[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 SoAWNsarAcYn for ; Sun, 21 Jun 2009 23:45:08 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 72A103A67C1 for ; Sun, 21 Jun 2009 23:45:08 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLM00AQVO3MK3@szxga03-in.huawei.com> for mext@ietf.org; Mon, 22 Jun 2009 14:45:22 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLM00HBAO3M42@szxga03-in.huawei.com> for mext@ietf.org; Mon, 22 Jun 2009 14:45:22 +0800 (CST) Received: from x65217 ([10.164.12.67]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLM006K1O3LA3@szxml04-in.huawei.com> for mext@ietf.org; Mon, 22 Jun 2009 14:45:22 +0800 (CST) Date: Mon, 22 Jun 2009 14:45:21 +0800 From: Jinwei Xia In-reply-to: <4A3E045F.2050605@it.uc3m.es> To: 'marcelo bagnulo braun' , 'mext' Message-id: <006501c9f305$03b79a00$430ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnyV2zo3PBr6B+XQKOc7XvGh26skAAq/3rw Subject: Re: [MEXT] early vs. late flow bindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 06:45:09 -0000 Hi Marcelo, Thank your clear clarification about flow bindings, some comments are inline > > A late binding would work as follows. The MN has a default > CoA through which it receives all flows that have no binding. > When the MN starts receiving a flow and the MN internal > policy states that this particular flow should flow through > an alternative CoA, it sends a flow binding message, saying > that _this_ particular flow (identified either by the 5-tuple > (src add, dest add, src port, dest port, protocol) or by the > 3-tuple (src add, dst add, SPI)) is bound to an alternative > CoA. When the HA receives this msg, it moves the flow to the > right CoA. > > An early binding is when the MN notifies the HA about what > are the flow descriptors of flows that should be forwarded > though each CoA. So, for instance the MN sends a flow binding > saying that all packets addressed to port TCP 80 > (irrespectively of the src and dst address) should be > forwarded to a given CoA. So, whenever a packet arrives for > port 80, it is directly forwarded to the selected CoA. >From the definitions of late and early flow binding, IMO it can be concluded as reactive and preactive mode flow binding respectively. And the essential difference is MN registers flow binding either voluntarily or triggered by outgoing flow traffic, right? It seems to be a inner implement work of MN. In such case, this topic should belong to the scope of MIF WG :-) If I am wrong, please correct me, thank you~! BR Jinwei > > Now, the disadvantage of the late binding is that it requires > sending a flow binding msg per new flow (so it is more > overhead) and it is reactive, so the first packets of the > flow would flow through the default CoA. the advantage of > early bindings is that we don't really need to encode in the > flow descriptors all kind of transport and application fields > that describe a flow. > > So, due to the aforementioned disadvantages of the early > bindings, i don't think it is optimal to only use early > bindings (even though it would be the cleaner approach imho). > However, imho we can certainly use the late bindings for > those flows that require more sophisticated flow descriptors. > So, imho, we should support the IP packet fields and the > protocol, src port and dst port as flow descriptors to be > used in early bindings and let all the rest of the flows that > cannot be properly described with these fields to be handled > with late bindings. > > comments? > > Regards, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Mon Jun 22 00:24:17 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 189683A685F for ; Mon, 22 Jun 2009 00:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.619 X-Spam-Level: X-Spam-Status: No, score=-6.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 CIhaqgshHTqg for ; Mon, 22 Jun 2009 00:24:13 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id DFF503A6359 for ; Mon, 22 Jun 2009 00:24:12 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (131.pool85-53-139.dynamic.orange.es [85.53.139.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 86E3865657E; Mon, 22 Jun 2009 09:24:25 +0200 (CEST) Message-ID: <4A3F31A9.3080907@it.uc3m.es> Date: Mon, 22 Jun 2009 09:24:25 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: w52006@huawei.com References: <003001c9f2e7$c9fba850$110ca40a@china.huawei.com> In-Reply-To: <003001c9f2e7$c9fba850$110ca40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16718.005 Cc: 'mext' Subject: Re: [MEXT] early vs. late flow bindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 07:24:17 -0000 Yungui Wang escribió: > Hello > > Do we need to differentiate whether a binding is the early binding > or the late binding? probably not, but it does influences how much do we need to express the different flows regards, marcelo > It seems implementation-specific. > > B.R. > Yungui > > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of marcelo bagnulo braun >> Sent: Sunday, June 21, 2009 5:59 PM >> To: mext >> Subject: [MEXT] early vs. late flow bindings >> >> Hi, >> >> I would like to make a comment on the flow binding approaches. >> >> First of all, i think it is important for this comment to >> clarify what is the minimum flow granularity we would like to >> > support. > >> I personally believe that the _minimum_ unit of flow that we >> would like to specify that it needs to be forwarded through a >> given CoA can be expressed either as: >> - src add, dst add, protocol, src port, dst port, or >> - src add, dst add, SPI >> >> So, do people think that we need to support higher >> granularity than this? I.e. that we need to send some packets >> of a TCP connection through one CoA and other packets of the >> same TCP connection through a different CoA? >> >> So, for the rest of the argument, I will assume that with >> this granularity suffices . >> So, when we want to bind a flow to a give CoA, we can do an >> early binding or a late binging. Let me explain what i mean >> by that (in case it not obvious from the wonderfully >> intuitive terminology i selected) >> >> A late binding would work as follows. The MN has a default >> CoA through which it receives all flows that have no binding. >> When the MN starts receiving a flow and the MN internal >> policy states that this particular flow should flow through >> an alternative CoA, it sends a flow binding message, saying >> that _this_ particular flow (identified either by the 5-tuple >> (src add, dest add, src port, dest port, protocol) or by the >> 3-tuple (src add, dst add, SPI)) is bound to an alternative >> CoA. When the HA receives this msg, it moves the flow to the >> right CoA. >> >> An early binding is when the MN notifies the HA about what >> are the flow descriptors of flows that should be forwarded >> though each CoA. So, for instance the MN sends a flow binding >> saying that all packets addressed to port TCP 80 >> (irrespectively of the src and dst address) should be >> forwarded to a given CoA. So, whenever a packet arrives for >> port 80, it is directly forwarded to the selected CoA. >> >> Now, the disadvantage of the late binding is that it requires >> sending a flow binding msg per new flow (so it is more >> overhead) and it is reactive, so the first packets of the >> flow would flow through the default CoA. the advantage of >> early bindings is that we don't really need to encode in the >> flow descriptors all kind of transport and application fields >> that describe a flow. >> >> So, due to the aforementioned disadvantages of the early >> bindings, i don't think it is optimal to only use early >> bindings (even though it would be the cleaner approach imho). >> However, imho we can certainly use the late bindings for >> those flows that require more sophisticated flow descriptors. >> So, imho, we should support the IP packet fields and the >> protocol, src port and dst port as flow descriptors to be >> used in early bindings and let all the rest of the flows that >> cannot be properly described with these fields to be handled >> with late bindings. >> >> comments? >> >> Regards, marcelo >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > > From marcelo@it.uc3m.es Mon Jun 22 00:25:57 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7E83A6964 for ; Mon, 22 Jun 2009 00:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.619 X-Spam-Level: X-Spam-Status: No, score=-6.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 5LkDuodmTae5 for ; Mon, 22 Jun 2009 00:25:56 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 3A4823A6359 for ; Mon, 22 Jun 2009 00:25:56 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (131.pool85-53-139.dynamic.orange.es [85.53.139.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 05CBD657358; Mon, 22 Jun 2009 09:26:09 +0200 (CEST) Message-ID: <4A3F3211.1050504@it.uc3m.es> Date: Mon, 22 Jun 2009 09:26:09 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jinwei Xia References: <006501c9f305$03b79a00$430ca40a@china.huawei.com> In-Reply-To: <006501c9f305$03b79a00$430ca40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16718.005 Cc: 'mext' Subject: Re: [MEXT] early vs. late flow bindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 07:25:57 -0000 Jinwei Xia escribió: > Hi Marcelo, > > Thank your clear clarification about flow bindings, some comments > are inline > > >> A late binding would work as follows. The MN has a default >> CoA through which it receives all flows that have no binding. >> When the MN starts receiving a flow and the MN internal >> policy states that this particular flow should flow through >> an alternative CoA, it sends a flow binding message, saying >> that _this_ particular flow (identified either by the 5-tuple >> (src add, dest add, src port, dest port, protocol) or by the >> 3-tuple (src add, dst add, SPI)) is bound to an alternative >> CoA. When the HA receives this msg, it moves the flow to the >> right CoA. >> >> An early binding is when the MN notifies the HA about what >> are the flow descriptors of flows that should be forwarded >> though each CoA. So, for instance the MN sends a flow binding >> saying that all packets addressed to port TCP 80 >> (irrespectively of the src and dst address) should be >> forwarded to a given CoA. So, whenever a packet arrives for >> port 80, it is directly forwarded to the selected CoA. >> > > >From the definitions of late and early flow binding, IMO it can be concluded > as reactive and preactive mode flow binding respectively. And the essential > difference is MN registers flow binding either voluntarily or triggered by > outgoing flow traffic, right? > right > It seems to be a inner implement work of MN. that may be true indeed > In such case, this topic should > belong to the scope of MIF WG :-) > i don't think so... afaict mobility specific issues are explicitly out of the scope of mif and this is certainly mip specific, since it deal with signalling to the HA Regards, marcelo > If I am wrong, please correct me, thank you~! > > > BR > Jinwei > > >> Now, the disadvantage of the late binding is that it requires >> sending a flow binding msg per new flow (so it is more >> overhead) and it is reactive, so the first packets of the >> flow would flow through the default CoA. the advantage of >> early bindings is that we don't really need to encode in the >> flow descriptors all kind of transport and application fields >> that describe a flow. >> >> So, due to the aforementioned disadvantages of the early >> bindings, i don't think it is optimal to only use early >> bindings (even though it would be the cleaner approach imho). >> However, imho we can certainly use the late bindings for >> those flows that require more sophisticated flow descriptors. >> So, imho, we should support the IP packet fields and the >> protocol, src port and dst port as flow descriptors to be >> used in early bindings and let all the rest of the flows that >> cannot be properly described with these fields to be handled >> with late bindings. >> >> comments? >> >> Regards, marcelo >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > > From yuri.ismailov@ericsson.com Mon Jun 22 01:50:44 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7781328C19D for ; Mon, 22 Jun 2009 01:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.87 X-Spam-Level: X-Spam-Status: No, score=-6.87 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 kUkfnV+rUZEr for ; Mon, 22 Jun 2009 01:50:43 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1FE2528C19A for ; Mon, 22 Jun 2009 01:50:41 -0700 (PDT) X-AuditID: c1b4fb3c-b7b0bae00000673a-a6-4a3f45dd781b Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 58.6F.26426.DD54F3A4; Mon, 22 Jun 2009 10:50:38 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jun 2009 10:49:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Jun 2009 10:48:59 +0200 Message-ID: In-Reply-To: <002f01c9f2dd$9b186050$110ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] "buffer" action for flow binding Thread-Index: Acnw70i8LOXaXYxpTP6WFfdMp1IkhQADWyIwAHaVOiAAD65aIA== References: <002f01c9f2dd$9b186050$110ca40a@china.huawei.com> From: "Yuri Ismailov" To: , "Eddy, Wesley M. (GRC-MS00)[Verizon]" , "Behcet Sarikaya" X-OriginalArrivalTime: 22 Jun 2009 08:49:01.0723 (UTC) FILETIME=[4A3ECEB0:01C9F316] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] "buffer" action for flow binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 08:50:44 -0000 Hi all, I believe we should not mix too different things: (1) where to place = functionality, and (2) which protocol to use to support this = functionality. Buffering, as a function may possibly placed in HA, but using of = mobility protocol for triggering that function probably not the best = choice. /yuri -----Original Message----- From: Yungui Wang [mailto:w52006@huawei.com]=20 Sent: Monday, June 22, 2009 4:03 AM To: 'Eddy, Wesley M. (GRC-MS00)[Verizon]'; 'Behcet Sarikaya'; Yuri = Ismailov Cc: mext@ietf.org Subject: RE: [MEXT] "buffer" action for flow binding Hello Thanks for your clarification.=20 My intent is an enhanced HA in which a ALG or backend server may be = located as Yuri said could do more things. More conveniently, DPI-like = technology (L3~L7) is more and more popular. I don't think it is very = difficult to be done. Here, what we need is a simple request from MN.=20 However, I am also not sure if the IP-layer request is appropriate. But, as I know, there is a similar example that a server located in/side = of a router (even side of AN) may buffer the multicast stream (a TV = channel or the important frames of a channel) for fast channel switch in = the fixed network. While, when a user sends a IP-layer request (IGMP) = for a new channel, the router (/server) may firstly push the buffered channel to the user, then do further works. B.R. Yungui > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf=20 > Of Eddy, Wesley M. (GRC-MS00)[Verizon] > Sent: Saturday, June 20, 2009 12:57 AM > To: Behcet Sarikaya > Cc: mext@ietf.org > Subject: Re: [MEXT] "buffer" action for flow binding >=20 > Yes, even for RTP it's very naive to assume that buffering in the HA=20 > is productive, and even for RTP it can be counterproductive. > If the end host player uses short buffers to bound delay in the=20 > application interactivity, the data you buffer in the HA will likely=20 > be below the playback pointer by the time it arrives, and simply be=20 > discarded. You'll also be wasting time and bandwidth transmitting=20 > this stale data across a possibly constrained link only to have to=20 > tossed away by the application. There are certainly thresholds where=20 > HA buffering could be useful to an A/V codec, but the time limits are=20 > quite heavily dependent on the specific application software and its=20 > local configuration which vary widely in the wild. The limited=20 > potential for good results combined with the definite possibility of=20 > bad results, and the inherent additional complexity make this a=20 > non-starter in my mind. >=20 > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- >=20 > >-----Original Message----- > >From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > >Sent: Friday, June 19, 2009 11:05 AM > >To: Eddy, Wesley M. (GRC-MS00)[Verizon] > >Cc: mext@ietf.org > >Subject: Re: [MEXT] "buffer" action for flow binding > > > > > >Hi Eddy, > >=A0 You are talking about pilc work (RFC 3366, etc.).=20 > Admittedly one can=20 > >show it either way. > >=A0 The point here is that not all flows are over TCP. In fact the=20 > >example given was a video call which will probably be RTP flow. RTP=20 > >does not control the transmission as much as TCP does. So=20 > buffering at=20 > >a point like HA could be useful, this seems intuitively correct.. > >=A0 Do you have any objection to that? > > > >Regards, > > > >Behcet > > > > > > > >----- Original Message ---- > >> From: "Eddy, Wesley M. (GRC-MS00)[Verizon]"=20 > > >> To: Behcet Sarikaya > >> Cc: "mext@ietf.org" > >> Sent: Thursday, June 18, 2009 8:00:52 PM > >> Subject: RE: [MEXT] "buffer" action for flow binding > >> > >> In general, it's enough to say that transports are robust to the > >temporary > >> network hiccups you throw at them, and this applies not=20 > only to TCP, > >but SCTP, > >> DCCP and other protocols as well.=A0 These all contain their own > >mechanisms for > >> estimating path properties and responding to changes in the path. > >Yes, there > >> may be a small performance dip, but the connections will=20 > live on and > >recover. > >> Hopefully you aren't handing over too frequently anyways ... and > >measurement > >> data shows that many/most TCP connections are quite short=20 > (only a few > >segments) > >> since webpages are only a small number of kB in size, on average. > >Sometimes the > >> buffering under discussion may be helpful; we can certainly tailor > >experiments > >> and simulations that show that ... we can also tailor=20 > simulations and=20 > >> experiments to show that it's dangerous and can cause performance > >degradation > >> instead of improvement under many conditions.=A0 IP is=20 > assumed to be a > >best-effort > >> service; no need to make it needlessly clever. > >> > >> Don't assume that the upper layers are so simple and fragile that=20 > >> they > >need > >> great amounts of help in order to perform, or you break=20 > them.=A0 There > >are many > >> papers on how link-layer ARQ leading to high jitter and=20 > delay spikes > >injures > >> end-to-end transport performance.=A0 RFC 3366 describes the danger in > >assuming > >> that high-persistence of the lower layers should be used in=20 > >> delivering > >TCP > >> segments and RFC 3481 documents a set of TCP extensions and tuning > >parameters > >> designed for robustness to links with handovers. > >> > >> There has also been an I-D discussed in TCPM several years=20 > ago about > >TCP-based > >> response to connectivity changes if they are visible to=20 > the transport > >and not > >> masked/hidden by the network layer: > >> http://tools.ietf.org/html/draft-schuetz-tcpm-tcp-rlci-03 > >> The references in that I-D to [SHUETZ] and [EDDY] can be=20 > found on the > >web and > >> contain simulation results showing performance issues that=20 > occur when > >the > >> network layer tries to hide path changes from the transport. > >> > >> > >> ________________________________________ > >> From: Behcet Sarikaya [behcetsarikaya@yahoo.com] > >> Sent: Thursday, June 18, 2009 6:42 PM > >> To: Eddy, Wesley M. (GRC-MS00)[Verizon] > >> Cc: mext@ietf.org > >> Subject: Re: [MEXT] "buffer" action for flow binding > >> > >> Hi Eddy, > >> =A0 Thank you for your advice. > >> However, I would like to know if you have any experimental data, > >research, > >> published papers, material to back it up. Please let us=20 > know. I know > >that TCP > >> behaviour in wireless links has been studied in depth but=20 > I for one=20 > >> am > >not aware > >> of any work on TCP and MIPv6 type of things, especially in this > >context. > >> > >> Regards, > >> > >> Behcet > >> > >> > >> > >> ----- Original Message ---- > >> > From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" > >> > To: Julien Laganier ; "w52006@huawei.com" > >> > >> > Cc: "mext@ietf.org" > >> > Sent: Thursday, June 18, 2009 12:15:32 PM > >> > Subject: Re: [MEXT] "buffer" action for flow binding > >> > > >> > I wouldn't advise trying to do too much optimization on=20 > behalf of=20 > >> > TCP.=A0 It depends on the length of time to perform the=20 > handover, but=20 > >> > longish handovers can run near the RTO and the data needing > >> > buffering during bulk-transfer is limited by the ACKs already=20 > >> > in-flight before handover due to the data segments being clocked=20 > >> > out by ACKs.=A0 For shorter handovers, TCP can handle the loss=20 > >> > detection and recovery efficiently through the fast=20 > >> > retransmission/recovery and SACK procedures.=A0 There is also an=20 > >> > argument some have made that TCP should be re- initiating=20 > >> > slow-start from its initial window after handovers due=20 > to the fact=20 > >> > that the path has completely changed and the state=20 > established on=20 > >> > the old path (cwnd, ssthresh, RTT, PMTU) may be invalid. > >> > > >> > Just a bit of caution and skepticism that buffering at=20 > the HA will=20 > >> > work exactly as intended in all cases ... even in the best case,=20 > >> > the buffering will cause an RTT spike. > >> > > >> > --------------------------- > >> > Wes Eddy > >> > Network & Systems Architect > >> > Verizon FNS / NASA GRC > >> > Office: (216) 433-6682 > >> > --------------------------- > >> > > >> > > >> > >-----Original Message----- > >> > >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > >Behalf Of > >> > >Julien Laganier > >> > >Sent: Thursday, June 18, 2009 8:07 AM > >> > >To: w52006@huawei.com > >> > >Cc: mext@ietf.org > >> > >Subject: Re: [MEXT] "buffer" action for flow binding > >> > > > >> > >Another potential usecase for buffering would be as follows: > >> > > > >> > >MN is receiving and/or sending bulk data transfer over=20 > TCP. Prior > >to > >> > >handover it requests HA to buffer downlink packets.=20 > After Handover > >it > >> > >requests HA to resume transmission of packets. In that=20 > way no TCP=20 > >> > >packets are lost because sent at the old MN CoA, and TCP > >transmission > >> > >rate is less impacted or not impacted at all by the handover. > >> > > > >> > >--julien > >> > > > >> > > > >> > >On Thu, Jun 18, 2009 at 4:59 AM, Yungui Wang wrote: > >> > > > >> > > > >> > >=A0 =A0 Hello > >> > > > >> > >=A0 =A0 There is a scenario for the HA service provider. > >> > > > >> > >=A0 =A0 One MN is watching a real-time TV service from internet. For > >> > >=A0 =A0 mobile IP service, > >> > >=A0 =A0 a video flow is created on HA. At the time, a video call is > >> > >=A0 =A0 incoming, the MN > >> > >=A0 =A0 decides to response the call and pause the TV=20 > service.=A0 Due to > >> > >=A0 =A0 lack of > >> > >=A0 =A0 bandwidth he can't receive and buffer it locally.=20 > He may then > >ask > >> > >=A0 =A0 the HA > >> > >=A0 =A0 buffering the TV flow un-interruptted. Thus, new action > >"Buffer" > >> > >=A0 =A0 may be > >> > >=A0 =A0 needed for flow binding. > >> > > > >> > >=A0 =A0 4 Buffer.=A0 This value indicates a request to buffer all=20 > >> > >packets > >> > >=A0 =A0 =A0 =A0 in the flow described by the option.=A0 No BIDs = are > >associated > >> > >=A0 =A0 with > >> > >=A0 =A0 =A0 =A0 this Action. > >> > > > >> > >=A0 =A0 Does it make sense? > >> > > > >> > > > >> > >=A0 =A0 B.R. > >> > >=A0 =A0 Yungui > >> > > > >> > > > >> > >=A0 =A0 _______________________________________________ > >> > >=A0 =A0 MEXT mailing list > >> > >=A0 =A0 MEXT@ietf.org > >> > >=A0 =A0 https://www.ietf.org/mailman/listinfo/mext > >> > > > >> > > > >> > > >> > _______________________________________________ > >> > MEXT mailing list > >> > MEXT@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 From nicolas@montavont.net Mon Jun 22 03:38:38 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF8073A6858 for ; Mon, 22 Jun 2009 03:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 i4B9GBtpE268 for ; Mon, 22 Jun 2009 03:38:36 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 6B6373A6964 for ; Mon, 22 Jun 2009 03:38:35 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so490946fga.18 for ; Mon, 22 Jun 2009 03:38:47 -0700 (PDT) Received: by 10.86.49.16 with SMTP id w16mr6419823fgw.67.1245667126927; Mon, 22 Jun 2009 03:38:46 -0700 (PDT) Received: from in025203.univ-rennes1.fr (in025203.univ-rennes1.fr [148.60.25.203]) by mx.google.com with ESMTPS id d6sm10035148fga.19.2009.06.22.03.38.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 22 Jun 2009 03:38:46 -0700 (PDT) Message-Id: From: Nicolas Montavont To: marcelo bagnulo braun In-Reply-To: <4A3E045F.2050605@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 22 Jun 2009 12:38:45 +0200 References: <4A3E045F.2050605@it.uc3m.es> X-Mailer: Apple Mail (2.935.3) Cc: mext Subject: Re: [MEXT] early vs. late flow bindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 10:38:38 -0000 Marcelo, On Jun 21, 2009, at 11:58 AM, marcelo bagnulo braun wrote: > Hi, > > I would like to make a comment on the flow binding approaches. > > First of all, i think it is important for this comment to clarify > what is the minimum flow granularity we would like to support. > I personally believe that the _minimum_ unit of flow that we would > like to specify that it needs to be forwarded through a given CoA > can be expressed either as: > - src add, dst add, protocol, src port, dst port, or > - src add, dst add, SPI > > So, do people think that we need to support higher granularity than > this? I.e. that we need to send some packets of a TCP connection > through one CoA and other packets of the same TCP connection through > a different CoA? > > So, for the rest of the argument, I will assume that with this > granularity suffices Let say that it is enough "in a first time". I mean, I am not sure we have enough experience with splitting a single connection into multiple paths, so maybe it is better to propose a specification just for the granularity of the flow. > > . > So, when we want to bind a flow to a give CoA, we can do an early > binding or a late binging. Let me explain what i mean by that (in > case it not obvious from the wonderfully intuitive terminology i > selected) > > A late binding would work as follows. The MN has a default CoA > through which it receives all flows that have no binding. When the > MN starts receiving a flow and the MN internal policy states that > this particular flow should flow through an alternative CoA, it > sends a flow binding message, saying that _this_ particular flow > (identified either by the 5-tuple (src add, dest add, src port, dest > port, protocol) or by the 3-tuple (src add, dst add, SPI)) is bound > to an alternative CoA. When the HA receives this msg, it moves the > flow to the right CoA. > > An early binding is when the MN notifies the HA about what are the > flow descriptors of flows that should be forwarded though each CoA. > So, for instance the MN sends a flow binding saying that all packets > addressed to port TCP 80 (irrespectively of the src and dst address) > should be forwarded to a given CoA. So, whenever a packet arrives > for port 80, it is directly forwarded to the selected CoA. > > Now, the disadvantage of the late binding is that it requires > sending a flow binding msg per new flow (so it is more overhead) and > it is reactive, so the first packets of the flow would flow through > the default CoA. the advantage of early bindings is that we don't > really need to encode in the flow descriptors all kind of transport > and application fields that describe a flow. I don't really see why you want to differentiate these two types of bindings flow to CoAs. I think we need both, because you'll probably want to install rules a priori, but you'll probably need to re-distribute flows in real time once a flow started. The two drafts we are proposing support these two behaviors (draft-ietf-mext-flow-binding and draft-tsirtsis-mext-binary- filters) Nicolas > > > So, due to the aforementioned disadvantages of the early bindings, i > don't think it is optimal to only use early bindings (even though it > would be the cleaner approach imho). However, imho we can certainly > use the late bindings for those flows that require more > sophisticated flow descriptors. So, imho, we should support the IP > packet fields and the protocol, src port and dst port as flow > descriptors to be used in early bindings and let all the rest of the > flows that cannot be properly described with these fields to be > handled with late bindings. > > comments? > > Regards, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From w52006@huawei.com Mon Jun 22 17:14:38 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263003A69EC for ; Mon, 22 Jun 2009 17:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.328 X-Spam-Level: X-Spam-Status: No, score=-0.328 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 YC3ryC7+NYTV for ; Mon, 22 Jun 2009 17:14:37 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id ED0CC3A6452 for ; Mon, 22 Jun 2009 17:14:36 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLO00MHJ0OIF7@szxga04-in.huawei.com> for mext@ietf.org; Tue, 23 Jun 2009 08:14:42 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLO009VN0OIGL@szxga04-in.huawei.com> for mext@ietf.org; Tue, 23 Jun 2009 08:14:42 +0800 (CST) Received: from w52006d ([10.164.12.17]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLO00MIW0OH6D@szxml04-in.huawei.com> for mext@ietf.org; Tue, 23 Jun 2009 08:14:42 +0800 (CST) Date: Tue, 23 Jun 2009 08:14:42 +0800 From: Yungui Wang In-reply-to: <4A3F31A9.3080907@it.uc3m.es> To: 'marcelo bagnulo braun' Message-id: <003601c9f397$9b20a930$110ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcnzDeKu2UcSoQO6S9WzVM3c6itN0gAA9zPw Cc: 'mext' Subject: Re: [MEXT] early vs. late flow bindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 00:14:38 -0000 Hello What's your intent?=20 Do you want to reflect the influence in flow binding, such as making some parameters mandatory/optional, etc.? Or, do you want to give us a guide to implement flow binding? Thanks. B.R. Yungui > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Monday, June 22, 2009 3:24 PM > To: w52006@huawei.com > Cc: 'mext' > Subject: Re: [MEXT] early vs. late flow bindings >=20 > Yungui Wang escribi=F3: > > Hello > > > > Do we need to differentiate whether a binding is the early=20 > binding or=20 > > the late binding? >=20 > probably not, but it does influences how much do we need to=20 > express the different flows >=20 > regards, marcelo >=20 >=20 > > It seems implementation-specific. > > > > B.R. > > Yungui > > =20 > > > > =20 > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 > On Behalf=20 > >> Of marcelo bagnulo braun > >> Sent: Sunday, June 21, 2009 5:59 PM > >> To: mext > >> Subject: [MEXT] early vs. late flow bindings > >> > >> Hi, > >> > >> I would like to make a comment on the flow binding approaches. > >> > >> First of all, i think it is important for this comment to clarify=20 > >> what is the minimum flow granularity we would like to > >> =20 > > support. > > =20 > >> I personally believe that the _minimum_ unit of flow that we would=20 > >> like to specify that it needs to be forwarded through a=20 > given CoA can=20 > >> be expressed either as: > >> - src add, dst add, protocol, src port, dst port, or > >> - src add, dst add, SPI > >> > >> So, do people think that we need to support higher=20 > granularity than=20 > >> this? I.e. that we need to send some packets of a TCP connection=20 > >> through one CoA and other packets of the same TCP=20 > connection through=20 > >> a different CoA? > >> > >> So, for the rest of the argument, I will assume that with this=20 > >> granularity suffices . > >> So, when we want to bind a flow to a give CoA, we can do an early=20 > >> binding or a late binging. Let me explain what i mean by that (in=20 > >> case it not obvious from the wonderfully intuitive terminology i=20 > >> selected) > >> > >> A late binding would work as follows. The MN has a default CoA=20 > >> through which it receives all flows that have no binding. > >> When the MN starts receiving a flow and the MN internal=20 > policy states=20 > >> that this particular flow should flow through an=20 > alternative CoA, it=20 > >> sends a flow binding message, saying that _this_ particular flow=20 > >> (identified either by the 5-tuple (src add, dest add, src=20 > port, dest=20 > >> port, protocol) or by the 3-tuple (src add, dst add, SPI))=20 > is bound=20 > >> to an alternative CoA. When the HA receives this msg, it moves the=20 > >> flow to the right CoA. > >> > >> An early binding is when the MN notifies the HA about what are the=20 > >> flow descriptors of flows that should be forwarded though=20 > each CoA.=20 > >> So, for instance the MN sends a flow binding saying that=20 > all packets=20 > >> addressed to port TCP 80 (irrespectively of the src and=20 > dst address)=20 > >> should be forwarded to a given CoA. So, whenever a packet=20 > arrives for=20 > >> port 80, it is directly forwarded to the selected CoA. > >> > >> Now, the disadvantage of the late binding is that it=20 > requires sending=20 > >> a flow binding msg per new flow (so it is more > >> overhead) and it is reactive, so the first packets of the=20 > flow would=20 > >> flow through the default CoA. the advantage of early=20 > bindings is that=20 > >> we don't really need to encode in the flow descriptors all kind of=20 > >> transport and application fields that describe a flow. > >> > >> So, due to the aforementioned disadvantages of the early=20 > bindings, i=20 > >> don't think it is optimal to only use early bindings (even=20 > though it=20 > >> would be the cleaner approach imho). > >> However, imho we can certainly use the late bindings for=20 > those flows=20 > >> that require more sophisticated flow descriptors. > >> So, imho, we should support the IP packet fields and the protocol,=20 > >> src port and dst port as flow descriptors to be used in early > >> bindings and let all the rest of the flows that cannot be properly=20 > >> described with these fields to be handled with late bindings. > >> > >> comments? > >> > >> Regards, marcelo > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > >> =20 > > > > > > =20 >=20 From w52006@huawei.com Mon Jun 22 17:31:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8FD43A6929 for ; Mon, 22 Jun 2009 17:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 mn+BcoQULmo1 for ; Mon, 22 Jun 2009 17:31:28 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2D7E93A6452 for ; Mon, 22 Jun 2009 17:31:28 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLO00JXG1GLRO@szxga04-in.huawei.com> for mext@ietf.org; Tue, 23 Jun 2009 08:31:33 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLO00GFE1GLG3@szxga04-in.huawei.com> for mext@ietf.org; Tue, 23 Jun 2009 08:31:33 +0800 (CST) Received: from w52006d ([10.164.12.17]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLO00MDG1GK6D@szxml04-in.huawei.com> for mext@ietf.org; Tue, 23 Jun 2009 08:31:33 +0800 (CST) Date: Tue, 23 Jun 2009 08:31:32 +0800 From: Yungui Wang In-reply-to: To: 'Yuri Ismailov' , "'Eddy, Wesley M. (GRC-MS00)[Verizon]'" , 'Behcet Sarikaya' Message-id: <003701c9f399$f5207260$110ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: Acnw70i8LOXaXYxpTP6WFfdMp1IkhQADWyIwAHaVOiAAD65aIAAggLsg Cc: mext@ietf.org Subject: Re: [MEXT] "buffer" action for flow binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 00:31:29 -0000 Hello Well, why is the action 'Discard' allowed? They both are affecting the flow self, not influencing CoA selection indeed.=20 If 'buffer' disallowed, nor 'Discard' does. Thanks. B.R. Yungui > -----Original Message----- > From: Yuri Ismailov [mailto:yuri.ismailov@ericsson.com]=20 > Sent: Monday, June 22, 2009 4:49 PM > To: w52006@huawei.com; Eddy, Wesley M. (GRC-MS00)[Verizon];=20 > Behcet Sarikaya > Cc: mext@ietf.org > Subject: RE: [MEXT] "buffer" action for flow binding >=20 > Hi all, > I believe we should not mix too different things: (1) where=20 > to place functionality, and (2) which protocol to use to=20 > support this functionality. > Buffering, as a function may possibly placed in HA, but using=20 > of mobility protocol for triggering that function probably=20 > not the best choice. >=20 > /yuri >=20 >=20 > -----Original Message----- > From: Yungui Wang [mailto:w52006@huawei.com] > Sent: Monday, June 22, 2009 4:03 AM > To: 'Eddy, Wesley M. (GRC-MS00)[Verizon]'; 'Behcet Sarikaya';=20 > Yuri Ismailov > Cc: mext@ietf.org > Subject: RE: [MEXT] "buffer" action for flow binding >=20 > Hello >=20 > Thanks for your clarification.=20 >=20 > My intent is an enhanced HA in which a ALG or backend server=20 > may be located as Yuri said could do more things. More=20 > conveniently, DPI-like technology (L3~L7) is more and more=20 > popular. I don't think it is very difficult to be done. Here,=20 > what we need is a simple request from MN.=20 > However, I am also not sure if the IP-layer request is appropriate. > But, as I know, there is a similar example that a server=20 > located in/side of a router (even side of AN) may buffer the=20 > multicast stream (a TV channel or the important frames of a=20 > channel) for fast channel switch in the fixed network. While,=20 > when a user sends a IP-layer request (IGMP) for a new=20 > channel, the router (/server) may firstly >=20 > push the buffered channel to the user, then do further works. >=20 > B.R. > Yungui >=20 > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 > On Behalf=20 > > Of Eddy, Wesley M. (GRC-MS00)[Verizon] > > Sent: Saturday, June 20, 2009 12:57 AM > > To: Behcet Sarikaya > > Cc: mext@ietf.org > > Subject: Re: [MEXT] "buffer" action for flow binding > >=20 > > Yes, even for RTP it's very naive to assume that buffering=20 > in the HA=20 > > is productive, and even for RTP it can be > counterproductive. > > If the end host player uses short buffers to bound delay in the=20 > > application interactivity, the data you buffer in the HA=20 > will likely=20 > > be below the playback pointer by the time it arrives, and simply be=20 > > discarded. You'll also be wasting time and bandwidth transmitting=20 > > this stale data across a possibly constrained link only to have to=20 > > tossed away by the application. There are certainly=20 > thresholds where=20 > > HA buffering could be useful to an A/V codec, but the time=20 > limits are=20 > > quite heavily dependent on the specific application=20 > software and its=20 > > local configuration which vary widely in the wild. The limited=20 > > potential for good results combined with the definite=20 > possibility of=20 > > bad results, and the inherent additional complexity make this a=20 > > non-starter in my > mind. > >=20 > > --------------------------- > > Wes Eddy > > Network & Systems Architect > > Verizon FNS / NASA GRC > > Office: (216) 433-6682 > > --------------------------- > >=20 > > >-----Original Message----- > > >From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > > >Sent: Friday, June 19, 2009 11:05 AM > > >To: Eddy, Wesley M. (GRC-MS00)[Verizon] > > >Cc: mext@ietf.org > > >Subject: Re: [MEXT] "buffer" action for flow binding > > > > > > > > >Hi Eddy, > > >=A0 You are talking about pilc work (RFC 3366, etc.).=20 > > Admittedly one can > > >show it either way. > > >=A0 The point here is that not all flows are over TCP. In fact > the=20 > > >example given was a video call which will probably be RTP flow. > RTP=20 > > >does not control the transmission as much as TCP does. So > > buffering at > > >a point like HA could be useful, this seems intuitively > correct.. > > >=A0 Do you have any objection to that? > > > > > >Regards, > > > > > >Behcet > > > > > > > > > > > >----- Original Message ---- > > >> From: "Eddy, Wesley M. (GRC-MS00)[Verizon]"=20 > > > > >> To: Behcet Sarikaya > > >> Cc: "mext@ietf.org" > > >> Sent: Thursday, June 18, 2009 8:00:52 PM > > >> Subject: RE: [MEXT] "buffer" action for flow binding > > >> > > >> In general, it's enough to say that transports are robust to > the > > >temporary > > >> network hiccups you throw at them, and this applies not > > only to TCP, > > >but SCTP, > > >> DCCP and other protocols as well.=A0 These all contain their > own > > >mechanisms for > > >> estimating path properties and responding to changes in the > path. > > >Yes, there > > >> may be a small performance dip, but the connections will > > live on and > > >recover. > > >> Hopefully you aren't handing over too frequently anyways ... > and > > >measurement > > >> data shows that many/most TCP connections are quite short > > (only a few > > >segments) > > >> since webpages are only a small number of kB in size, on > average. > > >Sometimes the > > >> buffering under discussion may be helpful; we can certainly > tailor > > >experiments > > >> and simulations that show that ... we can also tailor > > simulations and > > >> experiments to show that it's dangerous and can cause > performance > > >degradation > > >> instead of improvement under many conditions.=A0 IP is > > assumed to be a > > >best-effort > > >> service; no need to make it needlessly clever. > > >> > > >> Don't assume that the upper layers are so simple and fragile > that=20 > > >> they > > >need > > >> great amounts of help in order to perform, or you break > > them.=A0 There > > >are many > > >> papers on how link-layer ARQ leading to high jitter and > > delay spikes > > >injures > > >> end-to-end transport performance.=A0 RFC 3366 describes the > danger in > > >assuming > > >> that high-persistence of the lower layers should be used in > > >> delivering > > >TCP > > >> segments and RFC 3481 documents a set of TCP extensions and > tuning > > >parameters > > >> designed for robustness to links with handovers. > > >> > > >> There has also been an I-D discussed in TCPM several years > > ago about > > >TCP-based > > >> response to connectivity changes if they are visible to > > the transport > > >and not > > >> masked/hidden by the network layer: > > >> http://tools.ietf.org/html/draft-schuetz-tcpm-tcp-rlci-03 > > >> The references in that I-D to [SHUETZ] and [EDDY] can be > > found on the > > >web and > > >> contain simulation results showing performance issues that > > occur when > > >the > > >> network layer tries to hide path changes from the transport. > > >> > > >> > > >> ________________________________________ > > >> From: Behcet Sarikaya [behcetsarikaya@yahoo.com] > > >> Sent: Thursday, June 18, 2009 6:42 PM > > >> To: Eddy, Wesley M. (GRC-MS00)[Verizon] > > >> Cc: mext@ietf.org > > >> Subject: Re: [MEXT] "buffer" action for flow binding > > >> > > >> Hi Eddy, > > >> =A0 Thank you for your advice. > > >> However, I would like to know if you have any experimental > data, > > >research, > > >> published papers, material to back it up. Please let us > > know. I know > > >that TCP > > >> behaviour in wireless links has been studied in depth but > > I for one > > >> am > > >not aware > > >> of any work on TCP and MIPv6 type of things, especially in > this > > >context. > > >> > > >> Regards, > > >> > > >> Behcet > > >> > > >> > > >> > > >> ----- Original Message ---- > > >> > From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" > > >> > To: Julien Laganier ; "w52006@huawei.com" > > >> > > >> > Cc: "mext@ietf.org" > > >> > Sent: Thursday, June 18, 2009 12:15:32 PM > > >> > Subject: Re: [MEXT] "buffer" action for flow binding > > >> > > > >> > I wouldn't advise trying to do too much optimization on > > behalf of > > >> > TCP.=A0 It depends on the length of time to perform the > > handover, but > > >> > longish handovers can run near the RTO and the data needing >=20 > > >> > buffering during bulk-transfer is limited by the ACKs > already=20 > > >> > in-flight before handover due to the data segments being > clocked=20 > > >> > out by ACKs.=A0 For shorter handovers, TCP can handle the > loss=20 > > >> > detection and recovery efficiently through the fast=20 > > >> > retransmission/recovery and SACK procedures.=A0 There is also > an=20 > > >> > argument some have made that TCP should be re- initiating > > >> > slow-start from its initial window after handovers due=20 > > to the fact=20 > > >> > that the path has completely changed and the state=20 > > established on=20 > > >> > the old path (cwnd, ssthresh, RTT, PMTU) may be invalid. > > >> > > > >> > Just a bit of caution and skepticism that buffering at=20 > > the HA will=20 > > >> > work exactly as intended in all cases ... even in the best > case,=20 > > >> > the buffering will cause an RTT spike. > > >> > > > >> > --------------------------- > > >> > Wes Eddy > > >> > Network & Systems Architect > > >> > Verizon FNS / NASA GRC > > >> > Office: (216) 433-6682 > > >> > --------------------------- > > >> > > > >> > > > >> > >-----Original Message----- > > >> > >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > On > > >Behalf Of > > >> > >Julien Laganier > > >> > >Sent: Thursday, June 18, 2009 8:07 AM > > >> > >To: w52006@huawei.com > > >> > >Cc: mext@ietf.org > > >> > >Subject: Re: [MEXT] "buffer" action for flow binding > > >> > > > > >> > >Another potential usecase for buffering would be as > follows: > > >> > > > > >> > >MN is receiving and/or sending bulk data transfer over=20 > > TCP. Prior > > >to > > >> > >handover it requests HA to buffer downlink packets.=20 > > After Handover > > >it > > >> > >requests HA to resume transmission of packets. In that=20 > > way no TCP=20 > > >> > >packets are lost because sent at the old MN CoA, and TCP > > >transmission > > >> > >rate is less impacted or not impacted at all by the > handover. > > >> > > > > >> > >--julien > > >> > > > > >> > > > > >> > >On Thu, Jun 18, 2009 at 4:59 AM, Yungui Wang wrote: > > >> > > > > >> > > > > >> > >=A0 =A0 Hello > > >> > > > > >> > >=A0 =A0 There is a scenario for the HA service provider. > > >> > > > > >> > >=A0 =A0 One MN is watching a real-time TV service from > internet. For > > >> > >=A0 =A0 mobile IP service, > > >> > >=A0 =A0 a video flow is created on HA. At the time, a video > call is > > >> > >=A0 =A0 incoming, the MN > > >> > >=A0 =A0 decides to response the call and pause the TV=20 > > service.=A0 Due to > > >> > >=A0 =A0 lack of > > >> > >=A0 =A0 bandwidth he can't receive and buffer it locally.=20 > > He may then > > >ask > > >> > >=A0 =A0 the HA > > >> > >=A0 =A0 buffering the TV flow un-interruptted. Thus, new > action > > >"Buffer" > > >> > >=A0 =A0 may be > > >> > >=A0 =A0 needed for flow binding. > > >> > > > > >> > >=A0 =A0 4 Buffer.=A0 This value indicates a request to buffer > all=20 > > >> > >packets > > >> > >=A0 =A0 =A0 =A0 in the flow described by the option.=A0 No = BIDs are > > >associated > > >> > >=A0 =A0 with > > >> > >=A0 =A0 =A0 =A0 this Action. > > >> > > > > >> > >=A0 =A0 Does it make sense? > > >> > > > > >> > > > > >> > >=A0 =A0 B.R. > > >> > >=A0 =A0 Yungui > > >> > > > > >> > > > > >> > >=A0 =A0 _______________________________________________ > > >> > >=A0 =A0 MEXT mailing list > > >> > >=A0 =A0 MEXT@ietf.org > > >> > >=A0 =A0 https://www.ietf.org/mailman/listinfo/mext > > >> > > > > >> > > > > >> > > > >> > _______________________________________________ > > >> > MEXT mailing list > > >> > MEXT@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > >=20 > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > >=20 >=20 From yuri.ismailov@ericsson.com Tue Jun 23 05:21:56 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E3E628C0E5 for ; Tue, 23 Jun 2009 05:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.849 X-Spam-Level: X-Spam-Status: No, score=-6.849 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 uj5dSRJJrT-9 for ; Tue, 23 Jun 2009 05:21:54 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7B2663A6AE0 for ; Tue, 23 Jun 2009 05:21:52 -0700 (PDT) X-AuditID: c1b4fb3e-b7b99ae0000070a2-3d-4a40c1fa68b7 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 78.B9.28834.AF1C04A4; Tue, 23 Jun 2009 13:52:28 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 13:50:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jun 2009 13:50:52 +0200 Message-ID: In-Reply-To: <003701c9f399$f5207260$110ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] "buffer" action for flow binding Thread-Index: Acnw70i8LOXaXYxpTP6WFfdMp1IkhQADWyIwAHaVOiAAD65aIAAggLsgABdxuyA= References: <003701c9f399$f5207260$110ca40a@china.huawei.com> From: "Yuri Ismailov" To: , "Eddy, Wesley M. (GRC-MS00)[Verizon]" , "Behcet Sarikaya" X-OriginalArrivalTime: 23 Jun 2009 11:50:53.0784 (UTC) FILETIME=[DCC0ED80:01C9F3F8] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] "buffer" action for flow binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 12:21:56 -0000 Yungui, I'm entirely with you regarding 'Discard' action. I would add on top of = it other specified actions as well. I do not see how these actions = relate to mobility management. As you pointed out they are flow related = and in my view should be handled by applications. Moreover, specifically 'Discard' action, is quite usual firewall = function but not in any way mobility support function. And just one more time, the firewall function may be physically placed = in the HA. However, why would one change firewall rules using mobility = management protocol? I do not have any answer on that. I think that the origin of the problem is binary format (really sorry = for bringing it up again), where one cannot specify semantics of what = can be done with flows, just flow IDs. Thus, it is necessary to have a = number of options for delivering of such semantics. But not to forget = about the purpose of the semnatics it should be (according to the = charter) mobility management related. Using rules language would make = things much more easier, just because the semantics is the part of the = language description and parsing the language would produce unambiguios, = correct, synchronized on both ends binding cashes. Take again 'Discard' as an example. Semantically, one may come up with = quite strange operations, which are sintactically correct: Add new flow = binding and 'Discard' the flow. To avoid such things, the logic of = mutual exclusiveness of various actions and options has to be = introduced. Parsing the language, on the other hand would remove both semantical and = syntactical errors in operations, before producing meaningfull binding = caches. Regards Yuri -----Original Message----- From: Yungui Wang [mailto:w52006@huawei.com]=20 Sent: Tuesday, June 23, 2009 2:32 AM To: Yuri Ismailov; 'Eddy, Wesley M. (GRC-MS00)[Verizon]'; 'Behcet = Sarikaya' Cc: mext@ietf.org Subject: RE: [MEXT] "buffer" action for flow binding Hello Well, why is the action 'Discard' allowed? They both are affecting the flow self, not influencing CoA selection = indeed.=20 If 'buffer' disallowed, nor 'Discard' does. Thanks. B.R. Yungui > -----Original Message----- > From: Yuri Ismailov [mailto:yuri.ismailov@ericsson.com] > Sent: Monday, June 22, 2009 4:49 PM > To: w52006@huawei.com; Eddy, Wesley M. (GRC-MS00)[Verizon]; Behcet=20 > Sarikaya > Cc: mext@ietf.org > Subject: RE: [MEXT] "buffer" action for flow binding >=20 > Hi all, > I believe we should not mix too different things: (1) where to place=20 > functionality, and (2) which protocol to use to support this=20 > functionality. > Buffering, as a function may possibly placed in HA, but using of=20 > mobility protocol for triggering that function probably not the best=20 > choice. >=20 > /yuri >=20 >=20 > -----Original Message----- > From: Yungui Wang [mailto:w52006@huawei.com] > Sent: Monday, June 22, 2009 4:03 AM > To: 'Eddy, Wesley M. (GRC-MS00)[Verizon]'; 'Behcet Sarikaya'; Yuri=20 > Ismailov > Cc: mext@ietf.org > Subject: RE: [MEXT] "buffer" action for flow binding >=20 > Hello >=20 > Thanks for your clarification.=20 >=20 > My intent is an enhanced HA in which a ALG or backend server may be=20 > located as Yuri said could do more things. More conveniently, DPI-like = > technology (L3~L7) is more and more popular. I don't think it is very=20 > difficult to be done. Here, what we need is a simple request from MN. > However, I am also not sure if the IP-layer request is appropriate. > But, as I know, there is a similar example that a server located=20 > in/side of a router (even side of AN) may buffer the multicast stream=20 > (a TV channel or the important frames of a > channel) for fast channel switch in the fixed network. While, when a=20 > user sends a IP-layer request (IGMP) for a new channel, the router=20 > (/server) may firstly >=20 > push the buffered channel to the user, then do further works. >=20 > B.R. > Yungui >=20 > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > On Behalf > > Of Eddy, Wesley M. (GRC-MS00)[Verizon] > > Sent: Saturday, June 20, 2009 12:57 AM > > To: Behcet Sarikaya > > Cc: mext@ietf.org > > Subject: Re: [MEXT] "buffer" action for flow binding > >=20 > > Yes, even for RTP it's very naive to assume that buffering > in the HA > > is productive, and even for RTP it can be > counterproductive. > > If the end host player uses short buffers to bound delay in the=20 > > application interactivity, the data you buffer in the HA > will likely > > be below the playback pointer by the time it arrives, and simply be=20 > > discarded. You'll also be wasting time and bandwidth transmitting=20 > > this stale data across a possibly constrained link only to have to=20 > > tossed away by the application. There are certainly > thresholds where > > HA buffering could be useful to an A/V codec, but the time > limits are > > quite heavily dependent on the specific application > software and its > > local configuration which vary widely in the wild. The limited=20 > > potential for good results combined with the definite > possibility of > > bad results, and the inherent additional complexity make this a=20 > > non-starter in my > mind. > >=20 > > --------------------------- > > Wes Eddy > > Network & Systems Architect > > Verizon FNS / NASA GRC > > Office: (216) 433-6682 > > --------------------------- > >=20 > > >-----Original Message----- > > >From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > > >Sent: Friday, June 19, 2009 11:05 AM > > >To: Eddy, Wesley M. (GRC-MS00)[Verizon] > > >Cc: mext@ietf.org > > >Subject: Re: [MEXT] "buffer" action for flow binding > > > > > > > > >Hi Eddy, > > >=A0 You are talking about pilc work (RFC 3366, etc.).=20 > > Admittedly one can > > >show it either way. > > >=A0 The point here is that not all flows are over TCP. In fact > the > > >example given was a video call which will probably be RTP flow. > RTP > > >does not control the transmission as much as TCP does. So > > buffering at > > >a point like HA could be useful, this seems intuitively > correct.. > > >=A0 Do you have any objection to that? > > > > > >Regards, > > > > > >Behcet > > > > > > > > > > > >----- Original Message ---- > > >> From: "Eddy, Wesley M. (GRC-MS00)[Verizon]"=20 > > > > >> To: Behcet Sarikaya > > >> Cc: "mext@ietf.org" > > >> Sent: Thursday, June 18, 2009 8:00:52 PM > > >> Subject: RE: [MEXT] "buffer" action for flow binding > > >> > > >> In general, it's enough to say that transports are robust to > the > > >temporary > > >> network hiccups you throw at them, and this applies not > > only to TCP, > > >but SCTP, > > >> DCCP and other protocols as well.=A0 These all contain their > own > > >mechanisms for > > >> estimating path properties and responding to changes in the > path. > > >Yes, there > > >> may be a small performance dip, but the connections will > > live on and > > >recover. > > >> Hopefully you aren't handing over too frequently anyways ... > and > > >measurement > > >> data shows that many/most TCP connections are quite short > > (only a few > > >segments) > > >> since webpages are only a small number of kB in size, on > average. > > >Sometimes the > > >> buffering under discussion may be helpful; we can certainly > tailor > > >experiments > > >> and simulations that show that ... we can also tailor > > simulations and > > >> experiments to show that it's dangerous and can cause > performance > > >degradation > > >> instead of improvement under many conditions.=A0 IP is > > assumed to be a > > >best-effort > > >> service; no need to make it needlessly clever. > > >> > > >> Don't assume that the upper layers are so simple and fragile > that > > >> they > > >need > > >> great amounts of help in order to perform, or you break > > them.=A0 There > > >are many > > >> papers on how link-layer ARQ leading to high jitter and > > delay spikes > > >injures > > >> end-to-end transport performance.=A0 RFC 3366 describes the > danger in > > >assuming > > >> that high-persistence of the lower layers should be used in > > >> delivering > > >TCP > > >> segments and RFC 3481 documents a set of TCP extensions and > tuning > > >parameters > > >> designed for robustness to links with handovers. > > >> > > >> There has also been an I-D discussed in TCPM several years > > ago about > > >TCP-based > > >> response to connectivity changes if they are visible to > > the transport > > >and not > > >> masked/hidden by the network layer: > > >> http://tools.ietf.org/html/draft-schuetz-tcpm-tcp-rlci-03 > > >> The references in that I-D to [SHUETZ] and [EDDY] can be > > found on the > > >web and > > >> contain simulation results showing performance issues that > > occur when > > >the > > >> network layer tries to hide path changes from the transport. > > >> > > >> > > >> ________________________________________ > > >> From: Behcet Sarikaya [behcetsarikaya@yahoo.com] > > >> Sent: Thursday, June 18, 2009 6:42 PM > > >> To: Eddy, Wesley M. (GRC-MS00)[Verizon] > > >> Cc: mext@ietf.org > > >> Subject: Re: [MEXT] "buffer" action for flow binding > > >> > > >> Hi Eddy, > > >> =A0 Thank you for your advice. > > >> However, I would like to know if you have any experimental > data, > > >research, > > >> published papers, material to back it up. Please let us > > know. I know > > >that TCP > > >> behaviour in wireless links has been studied in depth but > > I for one > > >> am > > >not aware > > >> of any work on TCP and MIPv6 type of things, especially in > this > > >context. > > >> > > >> Regards, > > >> > > >> Behcet > > >> > > >> > > >> > > >> ----- Original Message ---- > > >> > From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" > > >> > To: Julien Laganier ; "w52006@huawei.com" > > >> > > >> > Cc: "mext@ietf.org" > > >> > Sent: Thursday, June 18, 2009 12:15:32 PM > > >> > Subject: Re: [MEXT] "buffer" action for flow binding > > >> > > > >> > I wouldn't advise trying to do too much optimization on > > behalf of > > >> > TCP.=A0 It depends on the length of time to perform the > > handover, but > > >> > longish handovers can run near the RTO and the data needing >=20 > > >> > buffering during bulk-transfer is limited by the ACKs > already > > >> > in-flight before handover due to the data segments being > clocked > > >> > out by ACKs.=A0 For shorter handovers, TCP can handle the > loss > > >> > detection and recovery efficiently through the fast=20 > > >> > retransmission/recovery and SACK procedures.=A0 There is also > an > > >> > argument some have made that TCP should be re- initiating > > >> > slow-start from its initial window after handovers due=20 > > to the fact=20 > > >> > that the path has completely changed and the state=20 > > established on=20 > > >> > the old path (cwnd, ssthresh, RTT, PMTU) may be invalid. > > >> > > > >> > Just a bit of caution and skepticism that buffering at=20 > > the HA will=20 > > >> > work exactly as intended in all cases ... even in the best > case,=20 > > >> > the buffering will cause an RTT spike. > > >> > > > >> > --------------------------- > > >> > Wes Eddy > > >> > Network & Systems Architect > > >> > Verizon FNS / NASA GRC > > >> > Office: (216) 433-6682 > > >> > --------------------------- > > >> > > > >> > > > >> > >-----Original Message----- > > >> > >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > On > > >Behalf Of > > >> > >Julien Laganier > > >> > >Sent: Thursday, June 18, 2009 8:07 AM > > >> > >To: w52006@huawei.com > > >> > >Cc: mext@ietf.org > > >> > >Subject: Re: [MEXT] "buffer" action for flow binding > > >> > > > > >> > >Another potential usecase for buffering would be as > follows: > > >> > > > > >> > >MN is receiving and/or sending bulk data transfer over=20 > > TCP. Prior > > >to > > >> > >handover it requests HA to buffer downlink packets.=20 > > After Handover > > >it > > >> > >requests HA to resume transmission of packets. In that=20 > > way no TCP=20 > > >> > >packets are lost because sent at the old MN CoA, and TCP > > >transmission > > >> > >rate is less impacted or not impacted at all by the > handover. > > >> > > > > >> > >--julien > > >> > > > > >> > > > > >> > >On Thu, Jun 18, 2009 at 4:59 AM, Yungui Wang wrote: > > >> > > > > >> > > > > >> > >=A0 =A0 Hello > > >> > > > > >> > >=A0 =A0 There is a scenario for the HA service provider. > > >> > > > > >> > >=A0 =A0 One MN is watching a real-time TV service from > internet. For > > >> > >=A0 =A0 mobile IP service, > > >> > >=A0 =A0 a video flow is created on HA. At the time, a video > call is > > >> > >=A0 =A0 incoming, the MN > > >> > >=A0 =A0 decides to response the call and pause the TV=20 > > service.=A0 Due to > > >> > >=A0 =A0 lack of > > >> > >=A0 =A0 bandwidth he can't receive and buffer it locally.=20 > > He may then > > >ask > > >> > >=A0 =A0 the HA > > >> > >=A0 =A0 buffering the TV flow un-interruptted. Thus, new > action > > >"Buffer" > > >> > >=A0 =A0 may be > > >> > >=A0 =A0 needed for flow binding. > > >> > > > > >> > >=A0 =A0 4 Buffer.=A0 This value indicates a request to buffer > all=20 > > >> > >packets > > >> > >=A0 =A0 =A0 =A0 in the flow described by the option.=A0 No = BIDs are > > >associated > > >> > >=A0 =A0 with > > >> > >=A0 =A0 =A0 =A0 this Action. > > >> > > > > >> > >=A0 =A0 Does it make sense? > > >> > > > > >> > > > > >> > >=A0 =A0 B.R. > > >> > >=A0 =A0 Yungui > > >> > > > > >> > > > > >> > >=A0 =A0 _______________________________________________ > > >> > >=A0 =A0 MEXT mailing list > > >> > >=A0 =A0 MEXT@ietf.org > > >> > >=A0 =A0 https://www.ietf.org/mailman/listinfo/mext > > >> > > > > >> > > > > >> > > > >> > _______________________________________________ > > >> > MEXT mailing list > > >> > MEXT@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > >=20 > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > >=20 >=20 From wesley.m.eddy@nasa.gov Wed Jun 24 11:39:16 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B98C3A67B4 for ; Wed, 24 Jun 2009 11:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 bt-tL6WbQDil for ; Wed, 24 Jun 2009 11:39:14 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 5E18328C4A9 for ; Wed, 24 Jun 2009 11:39:14 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 627E3D1E68; Wed, 24 Jun 2009 13:16:32 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04.ndc.nasa.gov [198.117.4.163]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n5OIGWb5032663; Wed, 24 Jun 2009 13:16:32 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Wed, 24 Jun 2009 13:16:32 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: Jari Arkko , "draft-ietf-mext-aero-reqs@tools.ietf.org" , "mext@ietf.org" Date: Wed, 24 Jun 2009 13:16:30 -0500 Thread-Topic: [MEXT] AD review of draft-ietf-mext-aero-reqs Thread-Index: AcnuxzHfucpP9AUXTy+Ut8Y1beBx1QGKtlGQ Message-ID: References: <4A380AB6.2080407@piuha.net> In-Reply-To: <4A380AB6.2080407@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-06-24_12:2009-06-01, 2009-06-24, 2009-06-24 signatures=0 Subject: Re: [MEXT] AD review of draft-ietf-mext-aero-reqs X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 18:39:16 -0000 >-----Original Message----- >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of >Jari Arkko >Sent: Tuesday, June 16, 2009 5:12 PM > >Substantial comments: > >> This version has been reviewed by members of the International Civil >> Aviation Orgnanization (ICAO) and other aeronautical communications >> standards bodies, and contributed to by a number of aeronautical >> communications experts outside the normal IETF process. >> > >What kind of review was actually performed? The above text sounds like a >formal review and acceptance was given. If something more informal was >actually done, please change the text accordingly. Also, "this version" >may not be appropriate as we intend to publish this as an RFC. Maybe >"Input to these requirements was given by aeronautical communications >experts outside the IETF, including members of the ...". The suggested change sounds appropriate to me; there was discussion at the ICAO WG-I #1 meeting and prior to that the original requirements were derived from an ICAO WG-N meeting's materials. I will update the draft. >> A need for high availability of connectivity to ground networks >> arises from the use of IP networking for carrying safety-of-life >> critical traffic. For this reason, single points of failure need to >> be avoided. If an RO solution assumes either a single MR onboard, a >> single HA, or some similar vulnerable point, and is not usable when >> the network includes standard reliability mechanisms for routers, >> then the RO technique will not be acceptable. An RO solution also >> MUST NOT itself imply a single point of failure. > >Hmm. There's a hidden requirement here that you actually cannot cope >with the basic NEMO at all (even without RO), because Mobile IP is by >its nature relies on a single point of failure (the HA). You _also_ need >another type of an extension to support multiple HAs for the same home >address. You should explicitly indicate that such a hidden requirement >exists and that its outside the scope of the RO work. Its good that the >end of 3.4.1 already says that Internet-less operation is ruled out, and >that HA/MR redundancy mechanisms are ruled out. But it would be good to >add the explicit note about this. Yes, this is right; we were always looking at the HA-redundancy extensions as well for deployment in this case. We can add a sentence to clarify. >Or are you thinking of using the RO solution as a way around this >requirement? To some small extent this would be possible. E.g., prefix >certificates could indicate to CRs that you can claim yourself as the >destination for a particular prefix. This would enable applications to >work. However, it would not enable a CN in some random location to send >a packet to the aircraft, unless the aircraft's MR had already >established RO with a router near the CN. The real requirement here is that beyond any existing fragility in the NEMO system, that the RO solution not add *new* single points of failure of its own creation. It could perhaps be rephrased somewhat in the draft to make that more clear. It was understood that if an HA was a single point of failure due to not using HA redundancy mechanisms, and it did in fact fail, then established sessions using RO could still operate based on the binding cache entries, but new incoming connections would not reach the MR/MN. So, having RO is nice in that it increases robustness to HA failure for established application flows, but it is not in itself a real solution for HA reliability, and that's not why it's asked for. >> The first security requirement is driven by concerns expressed by ATS >> communications engineers. The concern is with the air-ground links >> to a craft, and their current lack of security. If an RO scheme >> exposes the MNP to eavesdroppers on these links, it may enable >> attackers to easily send packets towards onboard networks of crafts. >> The RO scheme should use some reasonable form of encryption (e.g. >> standard ESP transforms) in order to protect any new RO signalling >> data that contains the MNP. > >I think you mean integrity protection or authentication, not encryption. >Encryption may not prevent the attacker from falsifying a signaling >packet. I would simply say ... reasonable security mechanisms (e.g., >strong authentication). Actually a concern here is that by sniffing the right frequency and seeing the MNP that is assigned to an aircraft, it will be very easy to track flights the way people currently do with ACARS, and even worse, it may be possible to find ways to direct packets at the planes based on this knowledge. There are many people sniffing ACARS from the air and tracking flights based on this today. >Also, I do not think the security of your networks can be based on the >MNP being a secret. The text is fuzzy about what the real issues are. >Note that I think the requirement from 3.8 was crystal clear. But the >3.8.1 text is making things a little more less clear. I would suggest >cutting some of the text. Ok; the MNP being secret is not a foundation of securing the system, but not broadcasting it to the world is something that raises the barriers to entry, and it's a request that was brought to us rather than something that the IETF decided was needed. >> The second security requirement is driven by the greater risk of >> flooding attacks that are started by an attacker redirecting an MNP's >> traffic to some target victim CoA. This is somewhat worse than the >> case for MIPv6 mobile host RO, because the MNP's traffic is >> potentially a higher rate than that of a single mobile host's HoA. >> To protect bindings to bogus CoAs from being sent, the RO scheme must >> somehow validate that an MR actually possesses any CoAs that it >> claims. In typical Mobile IPv6 RO, the return routability test >> provides a form of validation, under certain assumptions. For the >> purposes of aeronautics, to demonstrate ownership of the CoA, it is >> safe to assume ingress filtering on the part of the access network >> providers, in conjunction with the ability to correlate a BU's source >> address and the decrypted alternate CoA at the end recipient of the >> BU. (Note: this is particularly subject to MEXT discussion) > >Again, the requirement in 3.8 was great. The justifications are less >convincing. For instance, its not clear to me at all that a malicious MR >will have greater bandwidth than a malicious MN. I would simply say: > >"The second security requirement is driven by the risk of flooding >attacks that are started by an attacker redirecting an MNP's traffic to >some target victim CoA. To protect bindings to bogus CoAs from being >sent, the RO scheme must somehow validate that an MR actually possesses >any CoAs that it claims. For the purposes of aeronautics, it is safe to >assume ingress filtering is in place in the access networks." Ok; that makes sense to me, and sounds like a good change. >> It is felt by many individuals that by the time the IP-based ATN >> grows into production use, there will be a global PKI useable for >> ATS, though it is agreed that such a PKI does not currently exist, >> and will take time to develop both technically and politically. > >I think you mean s/global PKI/global ATN-specific PKI/. You should not >hold your breath for a global all-purpose PKI. :) Yes, of course. >> If the RO solution assumes that some amount >> of preconfiguration of flow properties (port number ranges, etc.) is >> required, this could make the integration of new applications or >> protocols difficult. An RO scheme might assume this in order to >> classify between flows that prefer the MRHA tunnel to an optimized >> path per requirement Req1, for instance, among other reasons. > >Req1 and this text under Req9 are in conflict. There is no way for a >middlebox like the MR to look at anything else than the 5-tuples for >doing traffic separation. Even without NEMO, your choices for providing >differentiated treatment for IPsec packets are limited. Basically, its >down to looking at addresses. (I think this would in fact most cases >suffice, so I do not see the real world problem.) > >So if Req9 is about disallowing 5-tuple based policies, we have a >problem. Perhaps you meant to say that RO still needs to be possible for >unrecognized stuff, and that it then get some sort of default treatment. What this requirement is saying is that the RO scheme must not assume only TCP traffic, for instance, and prevent new transports or other protocols from being deployed over the IP services provided. An implementation could still screw this up, but the RO mechanism as defined itself should be adaptable to new protocols. The actual requirement text is pretty clear: " Applications using new transport protocols, IPsec, or new IP options MUST be possible within an RO scheme." Maybe we have so much rationale that we made it confusing? We could definitely trim it a bit. >> 4.2. Des2 - Nesting >> >> >> It is desirable if the RO mechanism supports RO for nested MRs, >since >> it is possible that for PIES and astronaut spacesuits, that PANs >with >> MRs will need to be supported. For oceanic flight, ATS and AOS may >> also benefit from the capability of nesting MRs between multiple >> planes to provide a "reachback" to terrestrial groundstations >rather >> than relying solely on lower rate HF or satellite systems. In >either >> case, this mode of operation is beyond current strict requirements >> and is merely desirable. It is also noted that there are other >ways >> to support these communications scenarios using routing protocols >or >> other means outside of NEMO. > >Is loop detection a requirement? That is something that we do not >currently support in NEMO... Not a requirement at this stage of the game. >Editorial comments: > > ... All the editorial comments are basically good; here's just a quick answer to two of them: >> using Plain >> Old Aircraft Communication Addressing and Reporting System >(ACARS) >> > >Unless "Plain Old" is the formal name, I would use "using the old >Aircraft ..." instead. > >It would be good to get references to a few of the concepts and >technologies. E.g., Section 2 talks about ACARDS, VDL modes, Electronic >Flight Bags, B-AMC, AMACS, P34, LDL, WCDMA, 802.16, etc. Some of these >acronyms were not defined either. "Plain Old ACARS" is actually the industry-used term :), sometimes abbreviated POA (Plain Old ACARS). We can put in pointers to a couple of references on these things. >> satcom links employed by Connexion by Boeing support much higher data >rates than current ATS links. >> > >Isn't this history now? I would suggest rephrasing this without any >mention of specific products. E.g, satcom links employed by passenger >Internet access systems support much higher... Not totally history; Boeing Broadband Satcom Network lives on and is contracted at least through Feb 2010, based on public announcements. I suppose the name of the consumer-oriented service (Connexion) is history though, but the system is largely the same, I believe. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From marcelo@it.uc3m.es Fri Jun 26 14:26:11 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1C5128C159 for ; Fri, 26 Jun 2009 14:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 HoCdCpZ-M0-9 for ; Fri, 26 Jun 2009 14:25:59 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id EC4503A6C6D for ; Fri, 26 Jun 2009 14:25:57 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (133.pool85-53-136.dynamic.orange.es [85.53.136.133]) by smtp01.uc3m.es (Postfix) with ESMTP id 23735BA02E3; Fri, 26 Jun 2009 23:26:14 +0200 (CEST) Message-ID: <4A453CF5.7070707@it.uc3m.es> Date: Fri, 26 Jun 2009 23:26:13 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Hesham Soliman , "Tsirtsis, George" , mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16728.002 Subject: [MEXT] [Fwd: RE: [tsv-dir] TSV review of draft-ietf-mext-flow-binding-02.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 21:26:11 -0000 I am forwarding the TSV directorate review of the document. Please address the comments received. Thanks, marcelo -------- Mensaje original -------- Asunto: RE: [tsv-dir] TSV review of draft-ietf-mext-flow-binding-02.txt Fecha: Wed, 24 Jun 2009 09:02:00 -0500 De: Eddy, Wesley M. (GRC-MS00)[Verizon] Para: Lars Eggert , TSV Dir CC: Marcelo Bagnulo Braun , Jari Arkko , Julien Laganier Referencias: <4A2EB0FC.4080502@it.uc3m.es> <4A2EB2CF.7040404@piuha.net> <4B7CAC4C-F9C7-4EFF-AA3D-1F20D1BC77D6@nokia.com> I reviewed draft-ietf-mext-flow-binding-02 from a TSV perspective, and I've followed some of the MEXT mailing list threads around it. Overall, I think what's in the draft doesn't have major problems, and some of the proposals in this area that do have big TSV problems seem to be getting well-contained on the MEXT list. The one thing that needs to be discussed more between TSV and MEXT is the "n-cast" action (below). For the TSV perspective, the definition of flow descriptors and the possible actions performed on flows are of primary concern. This document actually punts on the definition of flow descriptors, and the actions it defines are limited to: - forward - discard - n-cast (replicate and forward to multiple addresses) Of these, n-cast is the one that bears some consideration. Obviously it can cause some duplication and reordering, so you would have to be careful to only do it for applications and transports that could handle that. It may have some interesting concerns for traditional means of PMTUD, congestion control, and other transport mechanisms that try to estimate path state and don't factor in the possibility that packets are being replicated across multiple paths. I don't fully understand the motivation for n-cast, beyond the possibility of a handover with reduced packet loss or something like that, so the pros and cons should be weighed carefully, I believe. Additionally, some mostly editorial comments: 1 - In the abstract and some other places there's a notion of "uplink" and "downlink" conveyed. I know we mean "outbound from the MN" and "inbound to the MN", so maybe we should say that instead? 2 - "Nemo" is usually "NEMO", in my experience, and would have to be changed throughout the document. 3 - The definitions of "Flow" and "Flow Description" are a bit circular in section 3. 4 - status field code 129 in flow identification option should probably be "malformed" or "unparseable" rather than "poorly formed" --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- >-----Original Message----- >From: tsv-dir-bounces@ietf.org [mailto:tsv-dir-bounces@ietf.org] On >Behalf Of Lars Eggert >Sent: Monday, June 15, 2009 7:06 AM >To: TSV Dir >Cc: Marcelo Bagnulo Braun; Jari Arkko; Julien Laganier >Subject: Re: [tsv-dir] TSV review of draft-ietf-mext-flow-binding-02.txt > >Hi, > >would someone please volunteer to perform this review for our friends >over in INT? > >Thanks, >Lars > >On 2009-6-9, at 22:06, Jari Arkko wrote: > >> And the primary question that I would like to have an answer for is: >> does this approach fly? If there's a major problem somewhere, we would >> like to know now when we can still change the approach. >> >> Jari >> >> marcelo bagnulo braun wrote: >>> Hi Lars, >>> >>> Our AD (Jari) has asked to request a TSV review of >>> http://www.ietf.org/internet-drafts/draft-ietf-mext-flow-binding- >02.txt >>> . >>> This document defines the transport of filter rules to bind flows to >>> different CoAs/interfaces. >>> the format for the flow description is not yet agreed, but in order >>> to >>> have an idea, there are two documents proposing a format for that: >>> http://tools.ietf.org/id/draft-tsirtsis-mext-binary-filters-00.txt >>> and >>> http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rules- >02.txt >>> >>> >>> We understand that the TSV review is critical for this document, >>> since >>> it deals with flows and how to define them, and it also involves >>> transporting a potentially larger piece of data than other MIP >>> extensions and aspects related to congestion control and >>> fragmentations of such messages may be relevant. >>> >>> So, if you could provide a review before the document reaches the >>> IESG, it would help to deal with any potential issue in an early >>> stage. >>> >>> thanks, marcelo >>> >>> >> From hesham@elevatemobile.com Fri Jun 26 21:38:07 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C20B33A67E3 for ; Fri, 26 Jun 2009 21:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.166, 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 nsKFwnCfgwto for ; Fri, 26 Jun 2009 21:38:06 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 4E4B03A67DD for ; Fri, 26 Jun 2009 21:38:05 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MKPg4-0007Ve-Ew; Sat, 27 Jun 2009 14:38:13 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Sat, 27 Jun 2009 14:37:56 +1000 From: Hesham Soliman To: marcelo bagnulo braun , "Tsirtsis, George" , mext Message-ID: Thread-Topic: [Fwd: RE: [tsv-dir] TSV review of draft-ietf-mext-flow-binding-02.txt] Thread-Index: Acn24QpwXJgl8+Hx3kelN9daPuUt0A== In-Reply-To: <4A453CF5.7070707@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [MEXT] [Fwd: RE: [tsv-dir] TSV review of draft-ietf-mext-flow-binding-02.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2009 04:38:07 -0000 Thanks for the review. I agree with you that we need to place cautions around the n-cast action and will do so based on the recommendaitons below. Specifically, mention that the MN should ensure that it is applied to appropriate transport layers that can handle potential re-ordering/duplications and mention that it's best applied to handover scenarios or scenarios where a redundant link is needed. Other editorials will be done as suggested. We already have suggestions for the circular definition. Hesham On 27/06/09 7:26 AM, "marcelo bagnulo braun" wrote: > I am forwarding the TSV directorate review of the document. Please > address the comments received. > Thanks, marcelo > > > -------- Mensaje original -------- > Asunto: RE: [tsv-dir] TSV review of draft-ietf-mext-flow-binding-02.txt > Fecha: Wed, 24 Jun 2009 09:02:00 -0500 > De: Eddy, Wesley M. (GRC-MS00)[Verizon] > Para: Lars Eggert , TSV Dir > CC: Marcelo Bagnulo Braun , Jari Arkko > , Julien Laganier > > Referencias: <4A2EB0FC.4080502@it.uc3m.es> <4A2EB2CF.7040404@piuha.net> > <4B7CAC4C-F9C7-4EFF-AA3D-1F20D1BC77D6@nokia.com> > > > > I reviewed draft-ietf-mext-flow-binding-02 from a TSV perspective, and > I've followed some of the MEXT mailing list threads around it. Overall, > I think what's in the draft doesn't have major problems, and some of the > proposals in this area that do have big TSV problems seem to be getting > well-contained on the MEXT list. The one thing that needs to be discussed > more between TSV and MEXT is the "n-cast" action (below). > > For the TSV perspective, the definition of flow descriptors and the > possible actions performed on flows are of primary concern. This > document actually punts on the definition of flow descriptors, and > the actions it defines are limited to: > > - forward > - discard > - n-cast (replicate and forward to multiple addresses) > > Of these, n-cast is the one that bears some consideration. Obviously > it can cause some duplication and reordering, so you would have to be > careful to only do it for applications and transports that could handle > that. It may have some interesting concerns for traditional means of > PMTUD, congestion control, and other transport mechanisms that try > to estimate path state and don't factor in the possibility that packets > are being replicated across multiple paths. I don't fully understand > the motivation for n-cast, beyond the possibility of a handover with > reduced packet loss or something like that, so the pros and cons should > be weighed carefully, I believe. > > Additionally, some mostly editorial comments: > > 1 - In the abstract and some other places there's a notion of "uplink" > and "downlink" conveyed. I know we mean "outbound from the MN" and > "inbound to the MN", so maybe we should say that instead? > > 2 - "Nemo" is usually "NEMO", in my experience, and would have to be > changed throughout the document. > > 3 - The definitions of "Flow" and "Flow Description" are a bit circular > in section 3. > > 4 - status field code 129 in flow identification option should probably > be "malformed" or "unparseable" rather than "poorly formed" > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > >> -----Original Message----- >> From: tsv-dir-bounces@ietf.org [mailto:tsv-dir-bounces@ietf.org] On >> Behalf Of Lars Eggert >> Sent: Monday, June 15, 2009 7:06 AM >> To: TSV Dir >> Cc: Marcelo Bagnulo Braun; Jari Arkko; Julien Laganier >> Subject: Re: [tsv-dir] TSV review of draft-ietf-mext-flow-binding-02.txt >> >> Hi, >> >> would someone please volunteer to perform this review for our friends >> over in INT? >> >> Thanks, >> Lars >> >> On 2009-6-9, at 22:06, Jari Arkko wrote: >> >>> And the primary question that I would like to have an answer for is: >>> does this approach fly? If there's a major problem somewhere, we would >>> like to know now when we can still change the approach. >>> >>> Jari >>> >>> marcelo bagnulo braun wrote: >>>> Hi Lars, >>>> >>>> Our AD (Jari) has asked to request a TSV review of >>>> http://www.ietf.org/internet-drafts/draft-ietf-mext-flow-binding- >> 02.txt >>>> . >>>> This document defines the transport of filter rules to bind flows to >>>> different CoAs/interfaces. >>>> the format for the flow description is not yet agreed, but in order >>>> to >>>> have an idea, there are two documents proposing a format for that: >>>> http://tools.ietf.org/id/draft-tsirtsis-mext-binary-filters-00.txt >>>> and >>>> http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rules- >> 02.txt >>>> >>>> >>>> We understand that the TSV review is critical for this document, >>>> since >>>> it deals with flows and how to define them, and it also involves >>>> transporting a potentially larger piece of data than other MIP >>>> extensions and aspects related to congestion control and >>>> fragmentations of such messages may be relevant. >>>> >>>> So, if you could provide a review before the document reaches the >>>> IESG, it would help to deal with any potential issue in an early >>>> stage. >>>> >>>> thanks, marcelo >>>> >>>> >>> > > From marcelo@it.uc3m.es Sun Jun 28 11:15:57 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7437E3A6AFD; Sun, 28 Jun 2009 11:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 TIq-Ko-W6xQy; Sun, 28 Jun 2009 11:15:56 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id B50903A6AF1; Sun, 28 Jun 2009 11:15:54 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (133.pool85-53-136.dynamic.orange.es [85.53.136.133]) by smtp03.uc3m.es (Postfix) with ESMTP id 046A3731E0F; Sun, 28 Jun 2009 20:16:11 +0200 (CEST) Message-ID: <4A47B36B.9030702@it.uc3m.es> Date: Sun, 28 Jun 2009 20:16:11 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: netext@ietf.org, mext , netlmm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16732.001 Cc: "Soininen Jonne \(NSN FI/Espoo\)" , Jari Arkko , netext-chairs@tools.ietf.org Subject: [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 18:15:57 -0000 Hi, This is a first draft of the BOF description for your consideration. It is still very open so, feel free to comment on whether the proposed approach seems appropriate or not. NETEXT2 BOF description ----------------------- Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to IP hosts without requiring any protocol enhancements or additional capabilities on the host. Current PMIP6 specification fully defines how to provide mobility support for mobile nodes with a single interface roaming in a PMIP6 domain. The goal of this BOF is gain understanding of how to support nodes with multiple interfaces (of possible different technologies) in a PMIP6 network. In particular, this BOF assumes the following scenario: We have a single PMIP6 domain that has deployed multiple access technologies and needs to support nodes that have multiple interfaces, possibly of different technologies. In particular, the following capabilities are needed: - Inter-technology handover support. The MN has initiated a communication over one interface and it needs to be able to move the established connection to a different interface of a possibly different technology. The reason for moving the communication to another interface is because of the MNs mobility and attaching via a different interface. Basically the ability to perform handovers that span different access technologies. - Multihoming support. The MN with multiple interfaces of possibly different technologies should be able to use them simultaneously to exchange data and manage the mobility of communications established through the different interfaces. - Flow mobility. A MN with multiple interfaces of possibly different technologies must be able to move a flow from one interface to another. Moreover, the MN should be able to inform the network through which interface it wishes to receive different types of flows. In order to provide the support for these capabilities, different approaches can be envisioned, namely: - L2 only approaches. In this type of approaches, the mechanisms to provide the required capabilities are fully L2 mechanisms and no modification of the IP layer is needed. - L3 only approaches. In this type of approaches, the mechanism to provide to required capabilities are located in the IP layer - Hybrid L2/L3 approaches. In this case, some mechanisms are located in L2 and other mechanisms are located in L3. Now, the different possible approaches vary greatly in their nature and resulting capabilities. To understanding the benefits and suitability of these alternatives, the requirements have to be properly defined and understood. The main goal of the BOF is understanding the need for work in the IETF in this area. In order to do so, during the BOF, we will attempt to: 1) Understand the applicable scenarios, and the problem statement related to those 2) Understand the restrictions and requirement imposed to solutions to address the problem statement and scenarios 3) Get an overview of the proposed solutions From Xiangsong.Cui@huawei.com Sun Jun 28 18:26:43 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051E73A68F1; Sun, 28 Jun 2009 18:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.219 X-Spam-Level: X-Spam-Status: No, score=0.219 tagged_above=-999 required=5 tests=[AWL=2.818, 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 Xwz73NNqfJHy; Sun, 28 Jun 2009 18:26:41 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B2D1F3A68C9; Sun, 28 Jun 2009 18:26:41 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLZ00IT8810QV@szxga04-in.huawei.com>; Mon, 29 Jun 2009 09:27:00 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLZ009G880ZA0@szxga04-in.huawei.com>; Mon, 29 Jun 2009 09:26:59 +0800 (CST) Date: Mon, 29 Jun 2009 09:27:01 +0800 From: Xiangsong Cui To: marcelo bagnulo braun , netext@ietf.org, mext , netlmm@ietf.org Message-id: <004101c9f858$b3f68d60$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A47B36B.9030702@it.uc3m.es> Cc: "Soininen Jonne \(NSN FI/Espoo\)" , Jari Arkko , netext-chairs@tools.ietf.org Subject: Re: [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 01:26:43 -0000 Hi Marcelo, I have a comment about the description. > - Inter-technology handover support. The MN has initiated a > communication over one interface and it needs to be able to move > the established connection to a different interface of ^^^^^^^^^ > a possibly different technology. I think "move the established communication" is better than "move the established connection". Because all the connections exist at the time if they have been established. What we move is the session or traffic flow, but not the connection. For example, there is a word from draft-ietf-mext-flow-binding-01.txt: "A single connection is typically identified by the source and destination IP addresses, transport protocol number and the source and destination port numbers. " (This sentence is modified in 02txt, but I think it is right.) Regards Xiangsong ----- Original Message ----- From: "marcelo bagnulo braun" To: ; "mext" ; Cc: "Soininen Jonne (NSN FI/Espoo)" ; "Jari Arkko" ; Sent: Monday, June 29, 2009 2:16 AM Subject: [MEXT] NEXTEXT2: first draft of the bof description > Hi, > > This is a first draft of the BOF description for your consideration. It is > still very open so, feel free to comment on whether the proposed approach > seems appropriate or not. > > NETEXT2 BOF description > ----------------------- > > Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility > protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to > IP hosts without requiring any protocol enhancements or additional > capabilities on the host. > Current PMIP6 specification fully defines how to provide mobility > support for mobile nodes with a single interface roaming in a PMIP6 > domain. The goal of this BOF is gain understanding of how to support > nodes with multiple interfaces (of possible different technologies) in a > PMIP6 network. > > In particular, this BOF assumes the following scenario: > We have a single PMIP6 domain that has deployed multiple > access technologies and needs to support nodes that have > multiple interfaces, possibly of different technologies. > > In particular, the following capabilities are needed: > > - Inter-technology handover support. The MN has initiated a > communication over one interface and it needs to be able to move > the established connection to a different interface of > a possibly different technology. The reason for moving > the communication to another interface is because of the MNs > mobility and attaching via a different interface. Basically > the ability to perform handovers that span different access > technologies. > > - Multihoming support. The MN with multiple interfaces of possibly > different technologies should be able to use them simultaneously to > exchange data and manage the mobility of communications > established through the different interfaces. > > - Flow mobility. A MN with multiple interfaces of possibly > different technologies must be able to move a flow from > one interface to another. Moreover, the MN should be able > to inform the network through which interface it wishes > to receive different types of flows. > > In order to provide the support for these capabilities, different > approaches can be envisioned, namely: > - L2 only approaches. In this type of approaches, the mechanisms > to provide the required capabilities are fully L2 mechanisms and > no modification of the IP layer is needed. > - L3 only approaches. In this type of approaches, the mechanism to > provide to required capabilities are located in the IP layer > - Hybrid L2/L3 approaches. In this case, some mechanisms are > located in L2 and other mechanisms are located in L3. > Now, the different possible approaches vary greatly in their nature > and resulting capabilities. To understanding the benefits and > suitability of these alternatives, the requirements have to be > properly defined and understood. > > The main goal of the BOF is understanding the need for work in the > IETF in this area. In order to do so, during the BOF, we will attempt to: > > 1) Understand the applicable scenarios, and the problem statement related > to > those > 2) Understand the restrictions and requirement imposed to solutions to > address the problem statement and scenarios > 3) Get an overview of the proposed solutions > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Sun Jun 28 23:41:53 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB213A67E5; Sun, 28 Jun 2009 23:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Zm6lD+VGckcv; Sun, 28 Jun 2009 23:41:52 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id B582C3A6AC6; Sun, 28 Jun 2009 23:41:50 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (133.pool85-53-136.dynamic.orange.es [85.53.136.133]) by smtp03.uc3m.es (Postfix) with ESMTP id D133872D159; Mon, 29 Jun 2009 08:42:07 +0200 (CEST) Message-ID: <4A48623F.5010506@it.uc3m.es> Date: Mon, 29 Jun 2009 08:42:07 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Xiangsong Cui References: <4A47B36B.9030702@it.uc3m.es> <004101c9f858$b3f68d60$40106f0a@china.huawei.com> In-Reply-To: <004101c9f858$b3f68d60$40106f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16732.004 Cc: netext@ietf.org, mext , netext-chairs@tools.ietf.org, Jari Arkko , "Soininen Jonne \(NSN FI/Espoo\)" , netlmm@ietf.org Subject: Re: [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 06:41:53 -0000 Xiangsong Cui escribió: > Hi Marcelo, > > I have a comment about the description. > >> - Inter-technology handover support. The MN has initiated a >> communication over one interface and it needs to be able to move >> the established connection to a different interface of > ^^^^^^^^^ >> a possibly different technology. > > I think "move the established communication" is better than "move the > established connection". agree regards, marcelo > Because all the connections exist at the time if they have been > established. What we move > is the session or traffic flow, but not the connection. For example, > there is a word from > draft-ietf-mext-flow-binding-01.txt: > > "A single connection is > typically identified by the source and destination IP addresses, > transport protocol number and the source and destination port > numbers. " (This sentence is modified in 02txt, but I think it is > right.) > > > Regards > > Xiangsong > > > > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: ; "mext" ; > Cc: "Soininen Jonne (NSN FI/Espoo)" ; "Jari > Arkko" ; > Sent: Monday, June 29, 2009 2:16 AM > Subject: [MEXT] NEXTEXT2: first draft of the bof description > > >> Hi, >> >> This is a first draft of the BOF description for your consideration. >> It is still very open so, feel free to comment on whether the >> proposed approach seems appropriate or not. >> >> NETEXT2 BOF description >> ----------------------- >> >> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility >> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to >> IP hosts without requiring any protocol enhancements or additional >> capabilities on the host. >> Current PMIP6 specification fully defines how to provide mobility >> support for mobile nodes with a single interface roaming in a PMIP6 >> domain. The goal of this BOF is gain understanding of how to support >> nodes with multiple interfaces (of possible different technologies) in a >> PMIP6 network. >> >> In particular, this BOF assumes the following scenario: >> We have a single PMIP6 domain that has deployed multiple >> access technologies and needs to support nodes that have >> multiple interfaces, possibly of different technologies. >> >> In particular, the following capabilities are needed: >> >> - Inter-technology handover support. The MN has initiated a >> communication over one interface and it needs to be able to move >> the established connection to a different interface of >> a possibly different technology. The reason for moving >> the communication to another interface is because of the MNs >> mobility and attaching via a different interface. Basically >> the ability to perform handovers that span different access >> technologies. >> >> - Multihoming support. The MN with multiple interfaces of possibly >> different technologies should be able to use them simultaneously to >> exchange data and manage the mobility of communications >> established through the different interfaces. >> >> - Flow mobility. A MN with multiple interfaces of possibly >> different technologies must be able to move a flow from >> one interface to another. Moreover, the MN should be able >> to inform the network through which interface it wishes >> to receive different types of flows. >> >> In order to provide the support for these capabilities, different >> approaches can be envisioned, namely: >> - L2 only approaches. In this type of approaches, the mechanisms >> to provide the required capabilities are fully L2 mechanisms and >> no modification of the IP layer is needed. >> - L3 only approaches. In this type of approaches, the mechanism to >> provide to required capabilities are located in the IP layer >> - Hybrid L2/L3 approaches. In this case, some mechanisms are >> located in L2 and other mechanisms are located in L3. >> Now, the different possible approaches vary greatly in their nature >> and resulting capabilities. To understanding the benefits and >> suitability of these alternatives, the requirements have to be >> properly defined and understood. >> >> The main goal of the BOF is understanding the need for work in the >> IETF in this area. In order to do so, during the BOF, we will attempt >> to: >> >> 1) Understand the applicable scenarios, and the problem statement >> related to >> those >> 2) Understand the restrictions and requirement imposed to solutions to >> address the problem statement and scenarios >> 3) Get an overview of the proposed solutions >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > From xiayangsong@huawei.com Mon Jun 29 09:17:15 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 228C03A6DCB; Mon, 29 Jun 2009 09:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.439 X-Spam-Level: X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] 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 nidyxTUlZZoo; Mon, 29 Jun 2009 09:17:14 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 046C03A6A32; Mon, 29 Jun 2009 09:17:14 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM000DDWD7Y77@szxga04-in.huawei.com>; Tue, 30 Jun 2009 00:16:46 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM0006V8D7X57@szxga04-in.huawei.com>; Tue, 30 Jun 2009 00:16:45 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM000F1SD7UOE@szxml06-in.huawei.com>; Tue, 30 Jun 2009 00:16:45 +0800 (CST) Date: Mon, 29 Jun 2009 11:16:42 -0500 From: Frank Xia To: marcelo bagnulo braun , netext@ietf.org, mext , netlmm@ietf.org Message-id: <000e01c9f8d4$ff2bde30$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A47B36B.9030702@it.uc3m.es> Cc: netext-chairs@tools.ietf.org Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 16:17:15 -0000 Hi Guys I have comments on inter-technology handover. IMHO, flow mobility could solve problems which inter-tech handover is try to deal with. I assume that two heterogeneous interfaces are all active during the handover. It is easy to move a flow(or all flows) from an interface to another. This is probably the reason why there is no inter-tech handover solution standerdized for client MIP. BR Frank ----- Original Message ----- From: "marcelo bagnulo braun" To: ; "mext" ; Cc: ; "Ralph Droms" Sent: Sunday, June 28, 2009 1:16 PM Subject: [netlmm] NEXTEXT2: first draft of the bof description > Hi, > > This is a first draft of the BOF description for your consideration. It is > still very open so, feel free to comment on whether the proposed approach > seems appropriate or not. > > NETEXT2 BOF description > ----------------------- > > Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility > protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to > IP hosts without requiring any protocol enhancements or additional > capabilities on the host. > Current PMIP6 specification fully defines how to provide mobility > support for mobile nodes with a single interface roaming in a PMIP6 > domain. The goal of this BOF is gain understanding of how to support > nodes with multiple interfaces (of possible different technologies) in a > PMIP6 network. > > In particular, this BOF assumes the following scenario: > We have a single PMIP6 domain that has deployed multiple > access technologies and needs to support nodes that have > multiple interfaces, possibly of different technologies. > > In particular, the following capabilities are needed: > > - Inter-technology handover support. The MN has initiated a > communication over one interface and it needs to be able to move > the established connection to a different interface of > a possibly different technology. The reason for moving > the communication to another interface is because of the MNs > mobility and attaching via a different interface. Basically > the ability to perform handovers that span different access > technologies. > > - Multihoming support. The MN with multiple interfaces of possibly > different technologies should be able to use them simultaneously to > exchange data and manage the mobility of communications > established through the different interfaces. > > - Flow mobility. A MN with multiple interfaces of possibly > different technologies must be able to move a flow from > one interface to another. Moreover, the MN should be able > to inform the network through which interface it wishes > to receive different types of flows. > > In order to provide the support for these capabilities, different > approaches can be envisioned, namely: > - L2 only approaches. In this type of approaches, the mechanisms > to provide the required capabilities are fully L2 mechanisms and > no modification of the IP layer is needed. > - L3 only approaches. In this type of approaches, the mechanism to > provide to required capabilities are located in the IP layer > - Hybrid L2/L3 approaches. In this case, some mechanisms are > located in L2 and other mechanisms are located in L3. > Now, the different possible approaches vary greatly in their nature > and resulting capabilities. To understanding the benefits and > suitability of these alternatives, the requirements have to be > properly defined and understood. > > The main goal of the BOF is understanding the need for work in the > IETF in this area. In order to do so, during the BOF, we will attempt to: > > 1) Understand the applicable scenarios, and the problem statement related > to > those > 2) Understand the restrictions and requirement imposed to solutions to > address the problem statement and scenarios > 3) Get an overview of the proposed solutions > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm From tsirtsis@googlemail.com Mon Jun 29 09:47:51 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E20D3A6BBB; Mon, 29 Jun 2009 09:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6] 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 Sc2tQnysNpxA; Mon, 29 Jun 2009 09:47:50 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 5EC2A3A6A67; Mon, 29 Jun 2009 09:47:49 -0700 (PDT) Received: by mail-bw0-f213.google.com with SMTP id 9so3380511bwz.37 for ; Mon, 29 Jun 2009 09:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=okonUw1/I2LIPWZjhQ2wq8NBRhqVgVxIemJxOj31zhM=; b=t5FXC4doWK5MOz/pljMQGrsPSzMWaLbRAxjKYZJOd9A+iFcqZK+3hpDFRFaJ4R1mjC Z0K7iAxHZgfhKVx+69/HqehMhVBsAAW7YHG/ktihE4sBL0RLggD+krxTnw8dAWGzgi+W Ja6bb8dGc7Hp2V6VLzZ5IBS2gvq3KRD5Nk1uI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SBaXoPBNdsynYKvyjHyTDp9EvO1xV0HnxRvA/yngh2Mq5aMn3cCqUdPsEpX0GedGy9 PLUIYCp/CPWbdaB784Aq54aBFRePH89Is+0/tHJTBovfFVBlWIDp+h15aRiij+a3O0Eu xgQJJb+pUnUVtIQ/j8WqxCp+5NHFSfxMFgXIQ= MIME-Version: 1.0 Received: by 10.223.107.199 with SMTP id c7mr4590961fap.31.1246294089723; Mon, 29 Jun 2009 09:48:09 -0700 (PDT) In-Reply-To: <000e01c9f8d4$ff2bde30$3e0c7c0a@china.huawei.com> References: <4A47B36B.9030702@it.uc3m.es> <000e01c9f8d4$ff2bde30$3e0c7c0a@china.huawei.com> Date: Mon, 29 Jun 2009 17:48:09 +0100 Message-ID: From: George Tsirtsis To: Frank Xia Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, netlmm@ietf.org, netext-chairs@tools.ietf.org, mext Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 16:47:51 -0000 Frank, your comment below is strange to say the least. MIP handoffs can be between interfaces of the same or different technologies. Since client MIP works at the IP layer (above the Link Layer of any specific technology) there is nothing that client MIP (and any of its features) need to specifically define for inter-technology handoffs. >Did you so far think that this means that client MIP only works intra-technology?< For PMIP, this is an issue because currently there is no defined protocol (on any layer) between MN and MAG...which is one of the issues to be discussed in netext2 bof. George On Mon, Jun 29, 2009 at 5:16 PM, Frank Xia wrote: > Hi Guys > > I have comments on inter-technology handover. > > IMHO, flow mobility could solve problems > which inter-tech handover is try to deal with. > I assume that two heterogeneous interfaces are > all active during the handover. =C2=A0It is easy to move > a flow(or all flows) from an interface to another. > > This is probably the reason why there is no > inter-tech handover solution standerdized > for client MIP. > > BR > Frank > > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: ; "mext" ; > Cc: ; "Ralph Droms" > Sent: Sunday, June 28, 2009 1:16 PM > Subject: [netlmm] NEXTEXT2: first draft of the bof description > > >> Hi, >> >> This is a first draft of the BOF description for your consideration. It = is >> still very open so, feel free to comment on whether the proposed approac= h >> seems appropriate or not. >> >> NETEXT2 BOF description >> ----------------------- >> >> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility >> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to >> IP hosts without requiring any protocol enhancements or additional >> capabilities on the host. >> Current PMIP6 specification fully defines how to provide mobility >> support for mobile nodes with a single interface roaming in a PMIP6 >> domain. The goal of this BOF is gain understanding of how to support >> nodes with multiple interfaces (of possible different technologies) in a >> PMIP6 network. >> >> In particular, this BOF assumes the following scenario: >> We have a single PMIP6 domain that has deployed multiple >> access technologies and needs to support nodes that have >> multiple interfaces, possibly of different technologies. >> >> In particular, the following capabilities are needed: >> >> - Inter-technology handover support. The MN has initiated a >> communication over one interface and it needs to be able to move >> the established connection to a different interface of >> a possibly different technology. The reason for moving >> the communication to another interface is because of the MNs >> mobility and attaching via a different interface. Basically >> the ability to perform handovers that span different access >> technologies. >> >> - Multihoming support. The MN with multiple interfaces of possibly >> different technologies should be able to use them simultaneously to >> exchange data and manage the mobility of communications >> established through the different interfaces. >> >> - Flow mobility. A MN with multiple interfaces of possibly >> different technologies must be able to move a flow from >> one interface to another. Moreover, the MN should be able >> to inform the network through which interface it wishes >> to receive different types of flows. >> >> In order to provide the support for these capabilities, different >> approaches can be envisioned, namely: >> - L2 only approaches. In this type of approaches, the mechanisms >> to provide the required capabilities are fully L2 mechanisms and >> no modification of the IP layer is needed. >> - L3 only approaches. In this type of approaches, the mechanism to >> provide to required capabilities are located in the IP layer >> - Hybrid L2/L3 approaches. In this case, some mechanisms are >> located in L2 and other mechanisms are located in L3. >> Now, the different possible approaches vary greatly in their nature >> and resulting capabilities. To understanding the benefits and >> suitability of these alternatives, the requirements have to be >> properly defined and understood. >> >> The main goal of the BOF is understanding the need for work in the >> IETF in this area. In order to do so, during the BOF, we will attempt to= : >> >> 1) Understand the applicable scenarios, and the problem statement relate= d >> to >> those >> 2) Understand the restrictions and requirement imposed to solutions to >> address the problem statement and scenarios >> 3) Get an overview of the proposed solutions >> >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From Basavaraj.Patil@nokia.com Mon Jun 29 09:50:09 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE2928C2A7; Mon, 29 Jun 2009 09:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] 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 fpZ7uUXyjodd; Mon, 29 Jun 2009 09:50:06 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id F00733A6B61; Mon, 29 Jun 2009 09:50:05 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5TGlQBn013309; Mon, 29 Jun 2009 11:50:04 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 19:49:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 19:49:55 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 29 Jun 2009 18:49:54 +0200 From: To: , , , , Date: Mon, 29 Jun 2009 18:50:02 +0200 Thread-Topic: [netlmm] NEXTEXT2: first draft of the bof description Thread-Index: Acn41RA+6tliGzrvT+KNALbUqm+P/gABJT0/ Message-ID: In-Reply-To: <000e01c9f8d4$ff2bde30$3e0c7c0a@china.huawei.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jun 2009 16:49:55.0066 (UTC) FILETIME=[A111CDA0:01C9F8D9] X-Nokia-AV: Clean Cc: netext-chairs@tools.ietf.org Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 16:50:09 -0000 Frank, On 6/29/09 11:16 AM, "ext Frank Xia" wrote: > Hi Guys >=20 > I have comments on inter-technology handover. >=20 > IMHO, flow mobility could solve problems > which inter-tech handover is try to deal with. Flow mobility also includes the ability to move a flow from one mobility session to another. Multiple mobility sessions could be established via a single interface in which case flow mobility would be achieved within the scope of a single interface. Hence flow mobility and inter-technology handovers are separate features. > I assume that two heterogeneous interfaces are > all active during the handover. It is easy to move > a flow(or all flows) from an interface to another. Possibly.. But the point is to identify what extensions (possibly to the MN= ) are needed in order to achieve handovers across interfaces. >=20 > This is probably the reason why there is no > inter-tech handover solution standerdized > for client MIP. Client MIP inherently supports handovers across multiple interfaces. Performance improvements to the handovers are accomplished using solutions such as FMIP. -Raj >=20 > BR > Frank >=20 > ----- Original Message ----- > From: "marcelo bagnulo braun" > To: ; "mext" ; > Cc: ; "Ralph Droms" > Sent: Sunday, June 28, 2009 1:16 PM > Subject: [netlmm] NEXTEXT2: first draft of the bof description >=20 >=20 >> Hi, >>=20 >> This is a first draft of the BOF description for your consideration. It = is >> still very open so, feel free to comment on whether the proposed approac= h >> seems appropriate or not. >>=20 >> NETEXT2 BOF description >> ----------------------- >>=20 >> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility >> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to >> IP hosts without requiring any protocol enhancements or additional >> capabilities on the host. >> Current PMIP6 specification fully defines how to provide mobility >> support for mobile nodes with a single interface roaming in a PMIP6 >> domain. The goal of this BOF is gain understanding of how to support >> nodes with multiple interfaces (of possible different technologies) in a >> PMIP6 network. >>=20 >> In particular, this BOF assumes the following scenario: >> We have a single PMIP6 domain that has deployed multiple >> access technologies and needs to support nodes that have >> multiple interfaces, possibly of different technologies. >>=20 >> In particular, the following capabilities are needed: >>=20 >> - Inter-technology handover support. The MN has initiated a >> communication over one interface and it needs to be able to move >> the established connection to a different interface of >> a possibly different technology. The reason for moving >> the communication to another interface is because of the MNs >> mobility and attaching via a different interface. Basically >> the ability to perform handovers that span different access >> technologies. >>=20 >> - Multihoming support. The MN with multiple interfaces of possibly >> different technologies should be able to use them simultaneously to >> exchange data and manage the mobility of communications >> established through the different interfaces. >>=20 >> - Flow mobility. A MN with multiple interfaces of possibly >> different technologies must be able to move a flow from >> one interface to another. Moreover, the MN should be able >> to inform the network through which interface it wishes >> to receive different types of flows. >>=20 >> In order to provide the support for these capabilities, different >> approaches can be envisioned, namely: >> - L2 only approaches. In this type of approaches, the mechanisms >> to provide the required capabilities are fully L2 mechanisms and >> no modification of the IP layer is needed. >> - L3 only approaches. In this type of approaches, the mechanism to >> provide to required capabilities are located in the IP layer >> - Hybrid L2/L3 approaches. In this case, some mechanisms are >> located in L2 and other mechanisms are located in L3. >> Now, the different possible approaches vary greatly in their nature >> and resulting capabilities. To understanding the benefits and >> suitability of these alternatives, the requirements have to be >> properly defined and understood. >>=20 >> The main goal of the BOF is understanding the need for work in the >> IETF in this area. In order to do so, during the BOF, we will attempt to= : >>=20 >> 1) Understand the applicable scenarios, and the problem statement relate= d >> to >> those >> 2) Understand the restrictions and requirement imposed to solutions to >> address the problem statement and scenarios >> 3) Get an overview of the proposed solutions >>=20 >>=20 >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www.ietf.org/mailman/listinfo/netlmm >=20 From xiayangsong@huawei.com Mon Jun 29 10:19:55 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30BBF28C2C6; Mon, 29 Jun 2009 10:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_42=0.6, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 Y3xSvcbPVZY0; Mon, 29 Jun 2009 10:19:54 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id D270328C2B6; Mon, 29 Jun 2009 10:19:53 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM000913G5FEZ@szxga01-in.huawei.com>; Tue, 30 Jun 2009 01:20:03 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM000HKJG5FUG@szxga01-in.huawei.com>; Tue, 30 Jun 2009 01:20:03 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM000F8TG5COA@szxml06-in.huawei.com>; Tue, 30 Jun 2009 01:20:03 +0800 (CST) Date: Mon, 29 Jun 2009 12:20:00 -0500 From: Frank Xia To: George Tsirtsis Message-id: <001401c9f8dd$d6c16830$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=utf-8; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A47B36B.9030702@it.uc3m.es> <000e01c9f8d4$ff2bde30$3e0c7c0a@china.huawei.com> Cc: netext@ietf.org, netlmm@ietf.org, netext-chairs@tools.ietf.org, mext Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 17:19:55 -0000 Hi Gorge It seems that I did not make me clear. 1)Single radio handover. MN should disconnect from one BS , and connect to a second BS. MN can't connect to the two BS at the same time. Handover solutions (FMIP/PMIP) are needed. 2)Dual radio handover MN connects to the two BS' at the same time. Flow mobility is sufficient when move a flow( or all flows) from one interface to another. BR Frank ----- Original Message ----- From: "George Tsirtsis" To: "Frank Xia" Cc: "marcelo bagnulo braun" ; ; "mext" ; ; Sent: Monday, June 29, 2009 11:48 AM Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof description Frank, your comment below is strange to say the least. MIP handoffs can be between interfaces of the same or different technologies. Since client MIP works at the IP layer (above the Link Layer of any specific technology) there is nothing that client MIP (and any of its features) need to specifically define for inter-technology handoffs. >Did you so far think that this means that client MIP only works intra-technology?< For PMIP, this is an issue because currently there is no defined protocol (on any layer) between MN and MAG...which is one of the issues to be discussed in netext2 bof. George On Mon, Jun 29, 2009 at 5:16 PM, Frank Xia wrote: > Hi Guys > > I have comments on inter-technology handover. > > IMHO, flow mobility could solve problems > which inter-tech handover is try to deal with. > I assume that two heterogeneous interfaces are > all active during the handover. It is easy to move > a flow(or all flows) from an interface to another. > > This is probably the reason why there is no > inter-tech handover solution standerdized > for client MIP. > > BR > Frank > > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: ; "mext" ; > Cc: ; "Ralph Droms" > Sent: Sunday, June 28, 2009 1:16 PM > Subject: [netlmm] NEXTEXT2: first draft of the bof description > > >> Hi, >> >> This is a first draft of the BOF description for your consideration. It >> is >> still very open so, feel free to comment on whether the proposed approach >> seems appropriate or not. >> >> NETEXT2 BOF description >> ----------------------- >> >> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility >> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to >> IP hosts without requiring any protocol enhancements or additional >> capabilities on the host. >> Current PMIP6 specification fully defines how to provide mobility >> support for mobile nodes with a single interface roaming in a PMIP6 >> domain. The goal of this BOF is gain understanding of how to support >> nodes with multiple interfaces (of possible different technologies) in a >> PMIP6 network. >> >> In particular, this BOF assumes the following scenario: >> We have a single PMIP6 domain that has deployed multiple >> access technologies and needs to support nodes that have >> multiple interfaces, possibly of different technologies. >> >> In particular, the following capabilities are needed: >> >> - Inter-technology handover support. The MN has initiated a >> communication over one interface and it needs to be able to move >> the established connection to a different interface of >> a possibly different technology. The reason for moving >> the communication to another interface is because of the MNs >> mobility and attaching via a different interface. Basically >> the ability to perform handovers that span different access >> technologies. >> >> - Multihoming support. The MN with multiple interfaces of possibly >> different technologies should be able to use them simultaneously to >> exchange data and manage the mobility of communications >> established through the different interfaces. >> >> - Flow mobility. A MN with multiple interfaces of possibly >> different technologies must be able to move a flow from >> one interface to another. Moreover, the MN should be able >> to inform the network through which interface it wishes >> to receive different types of flows. >> >> In order to provide the support for these capabilities, different >> approaches can be envisioned, namely: >> - L2 only approaches. In this type of approaches, the mechanisms >> to provide the required capabilities are fully L2 mechanisms and >> no modification of the IP layer is needed. >> - L3 only approaches. In this type of approaches, the mechanism to >> provide to required capabilities are located in the IP layer >> - Hybrid L2/L3 approaches. In this case, some mechanisms are >> located in L2 and other mechanisms are located in L3. >> Now, the different possible approaches vary greatly in their nature >> and resulting capabilities. To understanding the benefits and >> suitability of these alternatives, the requirements have to be >> properly defined and understood. >> >> The main goal of the BOF is understanding the need for work in the >> IETF in this area. In order to do so, during the BOF, we will attempt to: >> >> 1) Understand the applicable scenarios, and the problem statement related >> to >> those >> 2) Understand the restrictions and requirement imposed to solutions to >> address the problem statement and scenarios >> 3) Get an overview of the proposed solutions >> >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From Telemaco.Melia@alcatel-lucent.com Mon Jun 29 11:03:38 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785BF3A693F; Mon, 29 Jun 2009 11:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6] 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 FyCcT5Eqbxmq; Mon, 29 Jun 2009 11:03:37 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 0B9CA3A6B6A; Mon, 29 Jun 2009 11:03:36 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n5TI3VoG030199; Mon, 29 Jun 2009 20:03:39 +0200 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.32]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 20:03:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jun 2009 20:03:31 +0200 Message-ID: <853DD750D9C3724FBF2DF7164FCF641C032776AE@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: <001401c9f8dd$d6c16830$3e0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] [MEXT] NEXTEXT2: first draft of the bof description Thread-Index: Acn43e6XWrsspNs7SrmbP2Hrq1aAdgABX97Q References: <4A47B36B.9030702@it.uc3m.es><000e01c9f8d4$ff2bde30$3e0c7c0a@china.huawei.com> <001401c9f8dd$d6c16830$3e0c7c0a@china.huawei.com> From: "MELIA TELEMACO" To: "Frank Xia" , "George Tsirtsis" X-OriginalArrivalTime: 29 Jun 2009 18:03:33.0192 (UTC) FILETIME=[EA7A5480:01C9F8E3] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: netext@ietf.org, netlmm@ietf.org, netext-chairs@tools.ietf.org, mext Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 18:03:38 -0000 Frank, I think you should not mix flow mobility and inter-tech handover. A MN = might or might now use multiple connections at the same time... telemaco -----Message d'origine----- De=A0: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] De la = part de Frank Xia Envoy=E9=A0: lundi 29 juin 2009 19:20 =C0=A0: George Tsirtsis Cc=A0: netext@ietf.org; netlmm@ietf.org; netext-chairs@tools.ietf.org; = mext Objet=A0: Re: [netlmm] [MEXT] NEXTEXT2: first draft of the bof = description Hi Gorge It seems that I did not make me clear. 1)Single radio handover. MN should disconnect from one BS , and connect to a second BS. MN can't connect to the two BS at the same time. Handover solutions (FMIP/PMIP) are needed. 2)Dual radio handover MN connects to the two BS' at the same time. Flow mobility is sufficient when move a flow( or all flows) from one interface to another. BR Frank ----- Original Message -----=20 From: "George Tsirtsis" To: "Frank Xia" Cc: "marcelo bagnulo braun" ; ; = "mext"=20 ; ; Sent: Monday, June 29, 2009 11:48 AM Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof = description Frank, your comment below is strange to say the least. MIP handoffs can be between interfaces of the same or different technologies. Since client MIP works at the IP layer (above the Link Layer of any specific technology) there is nothing that client MIP (and any of its features) need to specifically define for inter-technology handoffs. >Did you so far think that this means that client MIP only works intra-technology?< For PMIP, this is an issue because currently there is no defined protocol (on any layer) between MN and MAG...which is one of the issues to be discussed in netext2 bof. George On Mon, Jun 29, 2009 at 5:16 PM, Frank Xia = wrote: > Hi Guys > > I have comments on inter-technology handover. > > IMHO, flow mobility could solve problems > which inter-tech handover is try to deal with. > I assume that two heterogeneous interfaces are > all active during the handover. It is easy to move > a flow(or all flows) from an interface to another. > > This is probably the reason why there is no > inter-tech handover solution standerdized > for client MIP. > > BR > Frank > > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: ; "mext" ; > Cc: ; "Ralph Droms" > Sent: Sunday, June 28, 2009 1:16 PM > Subject: [netlmm] NEXTEXT2: first draft of the bof description > > >> Hi, >> >> This is a first draft of the BOF description for your consideration. = It=20 >> is >> still very open so, feel free to comment on whether the proposed = approach >> seems appropriate or not. >> >> NETEXT2 BOF description >> ----------------------- >> >> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility >> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to >> IP hosts without requiring any protocol enhancements or additional >> capabilities on the host. >> Current PMIP6 specification fully defines how to provide mobility >> support for mobile nodes with a single interface roaming in a PMIP6 >> domain. The goal of this BOF is gain understanding of how to support >> nodes with multiple interfaces (of possible different technologies) = in a >> PMIP6 network. >> >> In particular, this BOF assumes the following scenario: >> We have a single PMIP6 domain that has deployed multiple >> access technologies and needs to support nodes that have >> multiple interfaces, possibly of different technologies. >> >> In particular, the following capabilities are needed: >> >> - Inter-technology handover support. The MN has initiated a >> communication over one interface and it needs to be able to move >> the established connection to a different interface of >> a possibly different technology. The reason for moving >> the communication to another interface is because of the MNs >> mobility and attaching via a different interface. Basically >> the ability to perform handovers that span different access >> technologies. >> >> - Multihoming support. The MN with multiple interfaces of possibly >> different technologies should be able to use them simultaneously to >> exchange data and manage the mobility of communications >> established through the different interfaces. >> >> - Flow mobility. A MN with multiple interfaces of possibly >> different technologies must be able to move a flow from >> one interface to another. Moreover, the MN should be able >> to inform the network through which interface it wishes >> to receive different types of flows. >> >> In order to provide the support for these capabilities, different >> approaches can be envisioned, namely: >> - L2 only approaches. In this type of approaches, the mechanisms >> to provide the required capabilities are fully L2 mechanisms and >> no modification of the IP layer is needed. >> - L3 only approaches. In this type of approaches, the mechanism to >> provide to required capabilities are located in the IP layer >> - Hybrid L2/L3 approaches. In this case, some mechanisms are >> located in L2 and other mechanisms are located in L3. >> Now, the different possible approaches vary greatly in their nature >> and resulting capabilities. To understanding the benefits and >> suitability of these alternatives, the requirements have to be >> properly defined and understood. >> >> The main goal of the BOF is understanding the need for work in the >> IETF in this area. In order to do so, during the BOF, we will attempt = to: >> >> 1) Understand the applicable scenarios, and the problem statement = related >> to >> those >> 2) Understand the restrictions and requirement imposed to solutions = to >> address the problem statement and scenarios >> 3) Get an overview of the proposed solutions >> >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www.ietf.org/mailman/listinfo/netlmm From xiayangsong@huawei.com Mon Jun 29 12:56:48 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41FB33A6BCC; Mon, 29 Jun 2009 12:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.442 X-Spam-Level: X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, STOX_REPLY_TYPE=0.001] 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 mTU8NvVu9i-U; Mon, 29 Jun 2009 12:56:47 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CFE253A6B00; Mon, 29 Jun 2009 12:56:46 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM00054ANF4OK@szxga04-in.huawei.com>; Tue, 30 Jun 2009 03:57:04 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM000969NF4LM@szxga04-in.huawei.com>; Tue, 30 Jun 2009 03:57:04 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM000HP5NF1R5@szxml04-in.huawei.com>; Tue, 30 Jun 2009 03:57:04 +0800 (CST) Date: Mon, 29 Jun 2009 14:57:00 -0500 From: Frank Xia To: Basavaraj.Patil@nokia.com, marcelo@it.uc3m.es, netext@ietf.org, mext@ietf.org, netlmm@ietf.org Message-id: <002701c9f8f3$c6007570$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Cc: netext-chairs@tools.ietf.org Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 19:56:48 -0000 Hi Raj My main point is make-before-break strategy is the best way to solve multi-radio handover. Please see my inline response. BR ----- Original Message ----- From: To: ; ; ; ; Cc: ; Sent: Monday, June 29, 2009 11:50 AM Subject: Re: [netlmm] NEXTEXT2: first draft of the bof description Frank, On 6/29/09 11:16 AM, "ext Frank Xia" wrote: > Hi Guys > > I have comments on inter-technology handover. > > IMHO, flow mobility could solve problems > which inter-tech handover is try to deal with. Flow mobility also includes the ability to move a flow from one mobility session to another. Multiple mobility sessions could be established via a single interface in which case flow mobility would be achieved within the scope of a single interface. Hence flow mobility and inter-technology handovers are separate features. Frank=>IMHO, inter-technology is trying to move all the traffic on one interface to another interface. > I assume that two heterogeneous interfaces are > all active during the handover. It is easy to move > a flow(or all flows) from an interface to another. Possibly.. But the point is to identify what extensions (possibly to the MN) are needed in order to achieve handovers across interfaces. Frank=>If we see inter-tech handover as a subset of flow mobility, there is one problem left, that is flow mobility. > > This is probably the reason why there is no > inter-tech handover solution standerdized > for client MIP. Client MIP inherently supports handovers across multiple interfaces. Performance improvements to the handovers are accomplished using solutions such as FMIP. Frank=>Maybe, I am missing something. However FMIP is not applicable to PAR/NAR collocated scenario. For example, a mobile node with two interface connects to the same access router (ASN-GW for WiMAX, PDN-GW for LTE). Does FMIP work when mobile node handover from one technology to another? -Raj > > BR > Frank > > ----- Original Message ----- > From: "marcelo bagnulo braun" > To: ; "mext" ; > Cc: ; "Ralph Droms" > Sent: Sunday, June 28, 2009 1:16 PM > Subject: [netlmm] NEXTEXT2: first draft of the bof description > > >> Hi, >> >> This is a first draft of the BOF description for your consideration. It >> is >> still very open so, feel free to comment on whether the proposed approach >> seems appropriate or not. >> >> NETEXT2 BOF description >> ----------------------- >> >> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility >> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to >> IP hosts without requiring any protocol enhancements or additional >> capabilities on the host. >> Current PMIP6 specification fully defines how to provide mobility >> support for mobile nodes with a single interface roaming in a PMIP6 >> domain. The goal of this BOF is gain understanding of how to support >> nodes with multiple interfaces (of possible different technologies) in a >> PMIP6 network. >> >> In particular, this BOF assumes the following scenario: >> We have a single PMIP6 domain that has deployed multiple >> access technologies and needs to support nodes that have >> multiple interfaces, possibly of different technologies. >> >> In particular, the following capabilities are needed: >> >> - Inter-technology handover support. The MN has initiated a >> communication over one interface and it needs to be able to move >> the established connection to a different interface of >> a possibly different technology. The reason for moving >> the communication to another interface is because of the MNs >> mobility and attaching via a different interface. Basically >> the ability to perform handovers that span different access >> technologies. >> >> - Multihoming support. The MN with multiple interfaces of possibly >> different technologies should be able to use them simultaneously to >> exchange data and manage the mobility of communications >> established through the different interfaces. >> >> - Flow mobility. A MN with multiple interfaces of possibly >> different technologies must be able to move a flow from >> one interface to another. Moreover, the MN should be able >> to inform the network through which interface it wishes >> to receive different types of flows. >> >> In order to provide the support for these capabilities, different >> approaches can be envisioned, namely: >> - L2 only approaches. In this type of approaches, the mechanisms >> to provide the required capabilities are fully L2 mechanisms and >> no modification of the IP layer is needed. >> - L3 only approaches. In this type of approaches, the mechanism to >> provide to required capabilities are located in the IP layer >> - Hybrid L2/L3 approaches. In this case, some mechanisms are >> located in L2 and other mechanisms are located in L3. >> Now, the different possible approaches vary greatly in their nature >> and resulting capabilities. To understanding the benefits and >> suitability of these alternatives, the requirements have to be >> properly defined and understood. >> >> The main goal of the BOF is understanding the need for work in the >> IETF in this area. In order to do so, during the BOF, we will attempt to: >> >> 1) Understand the applicable scenarios, and the problem statement related >> to >> those >> 2) Understand the restrictions and requirement imposed to solutions to >> address the problem statement and scenarios >> 3) Get an overview of the proposed solutions >> >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www.ietf.org/mailman/listinfo/netlmm > From stu.card@critical.com Mon Jun 29 13:11:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF8D728C167; Mon, 29 Jun 2009 13:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6] 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 2bza-2qY7S8A; Mon, 29 Jun 2009 13:11:19 -0700 (PDT) Received: from mail.critical.com (mail.critical.com [64.246.137.41]) by core3.amsl.com (Postfix) with ESMTP id 3593D3A6B0E; Mon, 29 Jun 2009 13:11:19 -0700 (PDT) Received: by mail.critical.com (Postfix, from userid 99) id 2AEE438012; Mon, 29 Jun 2009 16:11:39 -0400 (EDT) Received: from [192.168.1.3] (unknown [64.246.137.24]) by mail.critical.com (Postfix) with ESMTP id 9452D49B8; Mon, 29 Jun 2009 16:11:35 -0400 (EDT) Message-ID: <4A491FF4.10708@critical.com> Date: Mon, 29 Jun 2009 16:11:32 -0400 From: "Stuart W. Card" Organization: Critical Technologies Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mext@ietf.org References: <002701c9f8f3$c6007570$3e0c7c0a@china.huawei.com> In-Reply-To: <002701c9f8f3$c6007570$3e0c7c0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org, netext-chairs@tools.ietf.org, Basavaraj.Patil@nokia.com, netlmm@ietf.org Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 20:11:20 -0000 IMHO, inter-technology handoff and flow mobility overlap: neither is a strict subset of the other; but neither are they entirely independent. Make-before-break is certainly highly desirable, but perhaps should not be specified as required. Inter-technology handoff could be specified as moving _all_ flows from one interface to another, but that would needlessly over-constrain it: there clearly are cases where one might wish to move a sub-set of the flows (for instance, an old path may be losing capacity while a new one is gaining strength, but both are likely to remain usable for some time, so just shift some of the load). Frank Xia wrote: > Hi Raj > > My main point is make-before-break strategy > is the best way to solve multi-radio handover. > > Please see my inline response. > > BR > ----- Original Message ----- From: > To: ; ; ; > ; > Cc: ; > Sent: Monday, June 29, 2009 11:50 AM > Subject: Re: [netlmm] NEXTEXT2: first draft of the bof description > > > > Frank, > > > On 6/29/09 11:16 AM, "ext Frank Xia" wrote: > >> Hi Guys >> >> I have comments on inter-technology handover. >> >> IMHO, flow mobility could solve problems >> which inter-tech handover is try to deal with. > > Flow mobility also includes the ability to move a flow from one mobility > session to another. Multiple mobility sessions could be established via a > single interface in which case flow mobility would be achieved within the > scope of a single interface. Hence flow mobility and inter-technology > handovers are separate features. > Frank=>IMHO, inter-technology is trying to move all the traffic on > one interface to another interface. > >> I assume that two heterogeneous interfaces are >> all active during the handover. It is easy to move >> a flow(or all flows) from an interface to another. > > Possibly.. But the point is to identify what extensions (possibly to > the MN) > are needed in order to achieve handovers across interfaces. > Frank=>If we see inter-tech handover as a subset of flow mobility, > there is one problem left, that is flow mobility. > >> >> This is probably the reason why there is no >> inter-tech handover solution standerdized >> for client MIP. > > Client MIP inherently supports handovers across multiple interfaces. > Performance improvements to the handovers are accomplished using > solutions > such as FMIP. > Frank=>Maybe, I am missing something. However FMIP is not applicable > to PAR/NAR collocated scenario. For example, a mobile node with two > interface connects to the same access router (ASN-GW for WiMAX, > PDN-GW for LTE). Does FMIP work when mobile node handover from > one technology to another? > > -Raj > >> >> BR >> Frank >> >> ----- Original Message ----- >> From: "marcelo bagnulo braun" >> To: ; "mext" ; >> Cc: ; "Ralph Droms" >> Sent: Sunday, June 28, 2009 1:16 PM >> Subject: [netlmm] NEXTEXT2: first draft of the bof description >> >> >>> Hi, >>> >>> This is a first draft of the BOF description for your consideration. >>> It is >>> still very open so, feel free to comment on whether the proposed >>> approach >>> seems appropriate or not. >>> >>> NETEXT2 BOF description >>> ----------------------- >>> >>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility >>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to >>> IP hosts without requiring any protocol enhancements or additional >>> capabilities on the host. >>> Current PMIP6 specification fully defines how to provide mobility >>> support for mobile nodes with a single interface roaming in a PMIP6 >>> domain. The goal of this BOF is gain understanding of how to support >>> nodes with multiple interfaces (of possible different technologies) >>> in a >>> PMIP6 network. >>> >>> In particular, this BOF assumes the following scenario: >>> We have a single PMIP6 domain that has deployed multiple >>> access technologies and needs to support nodes that have >>> multiple interfaces, possibly of different technologies. >>> >>> In particular, the following capabilities are needed: >>> >>> - Inter-technology handover support. The MN has initiated a >>> communication over one interface and it needs to be able to move >>> the established connection to a different interface of >>> a possibly different technology. The reason for moving >>> the communication to another interface is because of the MNs >>> mobility and attaching via a different interface. Basically >>> the ability to perform handovers that span different access >>> technologies. >>> >>> - Multihoming support. The MN with multiple interfaces of possibly >>> different technologies should be able to use them simultaneously to >>> exchange data and manage the mobility of communications >>> established through the different interfaces. >>> >>> - Flow mobility. A MN with multiple interfaces of possibly >>> different technologies must be able to move a flow from >>> one interface to another. Moreover, the MN should be able >>> to inform the network through which interface it wishes >>> to receive different types of flows. >>> >>> In order to provide the support for these capabilities, different >>> approaches can be envisioned, namely: >>> - L2 only approaches. In this type of approaches, the mechanisms >>> to provide the required capabilities are fully L2 mechanisms and >>> no modification of the IP layer is needed. >>> - L3 only approaches. In this type of approaches, the mechanism to >>> provide to required capabilities are located in the IP layer >>> - Hybrid L2/L3 approaches. In this case, some mechanisms are >>> located in L2 and other mechanisms are located in L3. >>> Now, the different possible approaches vary greatly in their nature >>> and resulting capabilities. To understanding the benefits and >>> suitability of these alternatives, the requirements have to be >>> properly defined and understood. >>> >>> The main goal of the BOF is understanding the need for work in the >>> IETF in this area. In order to do so, during the BOF, we will >>> attempt to: >>> >>> 1) Understand the applicable scenarios, and the problem statement >>> related >>> to >>> those >>> 2) Understand the restrictions and requirement imposed to solutions to >>> address the problem statement and scenarios >>> 3) Get an overview of the proposed solutions >>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/netlmm >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > -- Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 www.critical.com From xiayangsong@huawei.com Mon Jun 29 13:22:21 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2234228C2E6; Mon, 29 Jun 2009 13:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, STOX_REPLY_TYPE=0.001] 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 enl4jeFDq+XG; Mon, 29 Jun 2009 13:22:20 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B6B633A6BAB; Mon, 29 Jun 2009 13:22:19 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM0005SQOLNOK@szxga04-in.huawei.com>; Tue, 30 Jun 2009 04:22:35 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM0009NBOLNLM@szxga04-in.huawei.com>; Tue, 30 Jun 2009 04:22:35 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM000FR2OLKN7@szxml06-in.huawei.com>; Tue, 30 Jun 2009 04:22:35 +0800 (CST) Date: Mon, 29 Jun 2009 15:22:31 -0500 From: Frank Xia To: MELIA TELEMACO , George Tsirtsis Message-id: <004b01c9f8f7$56779d60$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A47B36B.9030702@it.uc3m.es> <000e01c9f8d4$ff2bde30$3e0c7c0a@china.huawei.com> <001401c9f8dd$d6c16830$3e0c7c0a@china.huawei.com> <853DD750D9C3724FBF2DF7164FCF641C032776AE@FRVELSMBS14.ad2.ad.alcatel.com> Cc: netext@ietf.org, netlmm@ietf.org, netext-chairs@tools.ietf.org, mext Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 20:22:21 -0000 Hi Telemaco There are three use cases in my mind: 1)Two interfaces are active at the same time. This is the most common case. Flow mobility can handle all the problems relating to handover. 2)One interafce is active while the other is dormant. The dormant interface is activated before handover. Flow mobility can also do with it. 3)One interafce is active while the other is dormant, and traffic must be offloaded from the active one even though the dormant one is not ready. This is a rare case. If "inter-technology handover" focuses on dealing with this scenario, I am fine. BR Frank ----- Original Message ----- From: "MELIA TELEMACO" To: "Frank Xia" ; "George Tsirtsis" Cc: ; ; ; "mext" Sent: Monday, June 29, 2009 1:03 PM Subject: RE: [netlmm] [MEXT] NEXTEXT2: first draft of the bof description Frank, I think you should not mix flow mobility and inter-tech handover. A MN might or might now use multiple connections at the same time... telemaco -----Message d'origine----- De : netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] De la part de Frank Xia Envoyé : lundi 29 juin 2009 19:20 À : George Tsirtsis Cc : netext@ietf.org; netlmm@ietf.org; netext-chairs@tools.ietf.org; mext Objet : Re: [netlmm] [MEXT] NEXTEXT2: first draft of the bof description Hi Gorge It seems that I did not make me clear. 1)Single radio handover. MN should disconnect from one BS , and connect to a second BS. MN can't connect to the two BS at the same time. Handover solutions (FMIP/PMIP) are needed. 2)Dual radio handover MN connects to the two BS' at the same time. Flow mobility is sufficient when move a flow( or all flows) from one interface to another. BR Frank ----- Original Message ----- From: "George Tsirtsis" To: "Frank Xia" Cc: "marcelo bagnulo braun" ; ; "mext" ; ; Sent: Monday, June 29, 2009 11:48 AM Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof description Frank, your comment below is strange to say the least. MIP handoffs can be between interfaces of the same or different technologies. Since client MIP works at the IP layer (above the Link Layer of any specific technology) there is nothing that client MIP (and any of its features) need to specifically define for inter-technology handoffs. >Did you so far think that this means that client MIP only works intra-technology?< For PMIP, this is an issue because currently there is no defined protocol (on any layer) between MN and MAG...which is one of the issues to be discussed in netext2 bof. George On Mon, Jun 29, 2009 at 5:16 PM, Frank Xia wrote: > Hi Guys > > I have comments on inter-technology handover. > > IMHO, flow mobility could solve problems > which inter-tech handover is try to deal with. > I assume that two heterogeneous interfaces are > all active during the handover. It is easy to move > a flow(or all flows) from an interface to another. > > This is probably the reason why there is no > inter-tech handover solution standerdized > for client MIP. > > BR > Frank > > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: ; "mext" ; > Cc: ; "Ralph Droms" > Sent: Sunday, June 28, 2009 1:16 PM > Subject: [netlmm] NEXTEXT2: first draft of the bof description > > >> Hi, >> >> This is a first draft of the BOF description for your consideration. It >> is >> still very open so, feel free to comment on whether the proposed approach >> seems appropriate or not. >> >> NETEXT2 BOF description >> ----------------------- >> >> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility >> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to >> IP hosts without requiring any protocol enhancements or additional >> capabilities on the host. >> Current PMIP6 specification fully defines how to provide mobility >> support for mobile nodes with a single interface roaming in a PMIP6 >> domain. The goal of this BOF is gain understanding of how to support >> nodes with multiple interfaces (of possible different technologies) in a >> PMIP6 network. >> >> In particular, this BOF assumes the following scenario: >> We have a single PMIP6 domain that has deployed multiple >> access technologies and needs to support nodes that have >> multiple interfaces, possibly of different technologies. >> >> In particular, the following capabilities are needed: >> >> - Inter-technology handover support. The MN has initiated a >> communication over one interface and it needs to be able to move >> the established connection to a different interface of >> a possibly different technology. The reason for moving >> the communication to another interface is because of the MNs >> mobility and attaching via a different interface. Basically >> the ability to perform handovers that span different access >> technologies. >> >> - Multihoming support. The MN with multiple interfaces of possibly >> different technologies should be able to use them simultaneously to >> exchange data and manage the mobility of communications >> established through the different interfaces. >> >> - Flow mobility. A MN with multiple interfaces of possibly >> different technologies must be able to move a flow from >> one interface to another. Moreover, the MN should be able >> to inform the network through which interface it wishes >> to receive different types of flows. >> >> In order to provide the support for these capabilities, different >> approaches can be envisioned, namely: >> - L2 only approaches. In this type of approaches, the mechanisms >> to provide the required capabilities are fully L2 mechanisms and >> no modification of the IP layer is needed. >> - L3 only approaches. In this type of approaches, the mechanism to >> provide to required capabilities are located in the IP layer >> - Hybrid L2/L3 approaches. In this case, some mechanisms are >> located in L2 and other mechanisms are located in L3. >> Now, the different possible approaches vary greatly in their nature >> and resulting capabilities. To understanding the benefits and >> suitability of these alternatives, the requirements have to be >> properly defined and understood. >> >> The main goal of the BOF is understanding the need for work in the >> IETF in this area. In order to do so, during the BOF, we will attempt to: >> >> 1) Understand the applicable scenarios, and the problem statement related >> to >> those >> 2) Understand the restrictions and requirement imposed to solutions to >> address the problem statement and scenarios >> 3) Get an overview of the proposed solutions >> >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www.ietf.org/mailman/listinfo/netlmm From Basavaraj.Patil@nokia.com Mon Jun 29 13:44:36 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A9E628C2CB; Mon, 29 Jun 2009 13:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] 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 q5ZS8iTiTnLJ; Mon, 29 Jun 2009 13:44:35 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 62EB128C144; Mon, 29 Jun 2009 13:44:34 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5TKiKWG004728; Mon, 29 Jun 2009 23:44:26 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 23:43:18 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 23:43:13 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Mon, 29 Jun 2009 22:43:12 +0200 From: To: , , , , Date: Mon, 29 Jun 2009 22:43:18 +0200 Thread-Topic: [netext] [netlmm] NEXTEXT2: first draft of the bof description Thread-Index: Acn488zJEmhaC8GVSp+YJU0zJscx5gABm6uT Message-ID: In-Reply-To: <002701c9f8f3$c6007570$3e0c7c0a@china.huawei.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jun 2009 20:43:13.0952 (UTC) FILETIME=[390E4A00:01C9F8FA] X-Nokia-AV: Clean Cc: netext-chairs@tools.ietf.org Subject: Re: [MEXT] [netext] [netlmm] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 20:44:36 -0000 Hi Frank, Comments inline: On 6/29/09 2:57 PM, "ext Frank Xia" wrote: > Hi Raj >=20 > My main point is make-before-break strategy > is the best way to solve multi-radio handover. The IETF cannot do anything about whether an MN has the ability to accomplish make-before-break connectivity. It depends on the link-layer technology, spectrum that they operate in, etc. So this approach is a non-starter. The IETF solution has to be agnostic to underlying access technologies.=20 >=20 > Please see my inline response. >=20 > BR > ----- Original Message ----- > From: > To: ; ; ; > ; > Cc: ; > Sent: Monday, June 29, 2009 11:50 AM > Subject: Re: [netlmm] NEXTEXT2: first draft of the bof description >=20 >=20 >=20 > Frank, >=20 >=20 > On 6/29/09 11:16 AM, "ext Frank Xia" wrote: >=20 >> Hi Guys >>=20 >> I have comments on inter-technology handover. >>=20 >> IMHO, flow mobility could solve problems >> which inter-tech handover is try to deal with. >=20 > Flow mobility also includes the ability to move a flow from one mobility > session to another. Multiple mobility sessions could be established via a > single interface in which case flow mobility would be achieved within the > scope of a single interface. Hence flow mobility and inter-technology > handovers are separate features. > Frank=3D>IMHO, inter-technology is trying to move all the traffic on > one interface to another interface. Right. I guess you answered the question about the difference between flow mobility and inter-technology handovers. You could extrapolate and say that inter-technology HO is the case where you move all flows from one interface to another and hence a variant of flow mobility. While that is true, you should also recognize that the granularity of flow mobility is finer and does not have to necessarily be a relocation of a flow between physical interfaces.=20 >=20 >> I assume that two heterogeneous interfaces are >> all active during the handover. It is easy to move >> a flow(or all flows) from an interface to another. >=20 > Possibly.. But the point is to identify what extensions (possibly to the = MN) > are needed in order to achieve handovers across interfaces. > Frank=3D>If we see inter-tech handover as a subset of flow mobility, > there is one problem left, that is flow mobility. See above. Flow mobility is a feature that can work across multiple mobilit= y sessions within the scope of a single interface as well. >=20 >>=20 >> This is probably the reason why there is no >> inter-tech handover solution standerdized >> for client MIP. >=20 > Client MIP inherently supports handovers across multiple interfaces. > Performance improvements to the handovers are accomplished using solution= s > such as FMIP. > Frank=3D>Maybe, I am missing something. However FMIP is not applicable > to PAR/NAR collocated scenario. For example, a mobile node with two > interface connects to the same access router (ASN-GW for WiMAX, > PDN-GW for LTE). Does FMIP work when mobile node handover from > one technology to another? Not sure I understand the question. In your example above, I believe the MN would connect to the ASN-GW via the WiMAX interface and to an S-GW via the LTE interface. The P-GW (LMA) may be the same. If the question is, can you use FMIP to optimize handovers in such a scenario... Yes. Not FMIP, but PFMIP6 (ref. MIPSHOP WG I-D). But I don't think we are looking at optimizin= g handovers in this discussion. As per the current PMIP6 specification wherein no changes to the host are required, it is not possible to do an inter-technology handover. This is a limitation which implies that PMIP6 provides host mobility to an MN within the scope of a single access technology. Host based mobile IP does not have this problem. =20 -Raj >=20 > -Raj >=20 >>=20 >> BR >> Frank >>=20 >> ----- Original Message ----- >> From: "marcelo bagnulo braun" >> To: ; "mext" ; >> Cc: ; "Ralph Droms" >> Sent: Sunday, June 28, 2009 1:16 PM >> Subject: [netlmm] NEXTEXT2: first draft of the bof description >>=20 >>=20 >>> Hi, >>>=20 >>> This is a first draft of the BOF description for your consideration. It >>> is >>> still very open so, feel free to comment on whether the proposed approa= ch >>> seems appropriate or not. >>>=20 >>> NETEXT2 BOF description >>> ----------------------- >>>=20 >>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility >>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to >>> IP hosts without requiring any protocol enhancements or additional >>> capabilities on the host. >>> Current PMIP6 specification fully defines how to provide mobility >>> support for mobile nodes with a single interface roaming in a PMIP6 >>> domain. The goal of this BOF is gain understanding of how to support >>> nodes with multiple interfaces (of possible different technologies) in = a >>> PMIP6 network. >>>=20 >>> In particular, this BOF assumes the following scenario: >>> We have a single PMIP6 domain that has deployed multiple >>> access technologies and needs to support nodes that have >>> multiple interfaces, possibly of different technologies. >>>=20 >>> In particular, the following capabilities are needed: >>>=20 >>> - Inter-technology handover support. The MN has initiated a >>> communication over one interface and it needs to be able to move >>> the established connection to a different interface of >>> a possibly different technology. The reason for moving >>> the communication to another interface is because of the MNs >>> mobility and attaching via a different interface. Basically >>> the ability to perform handovers that span different access >>> technologies. >>>=20 >>> - Multihoming support. The MN with multiple interfaces of possibly >>> different technologies should be able to use them simultaneously to >>> exchange data and manage the mobility of communications >>> established through the different interfaces. >>>=20 >>> - Flow mobility. A MN with multiple interfaces of possibly >>> different technologies must be able to move a flow from >>> one interface to another. Moreover, the MN should be able >>> to inform the network through which interface it wishes >>> to receive different types of flows. >>>=20 >>> In order to provide the support for these capabilities, different >>> approaches can be envisioned, namely: >>> - L2 only approaches. In this type of approaches, the mechanisms >>> to provide the required capabilities are fully L2 mechanisms and >>> no modification of the IP layer is needed. >>> - L3 only approaches. In this type of approaches, the mechanism to >>> provide to required capabilities are located in the IP layer >>> - Hybrid L2/L3 approaches. In this case, some mechanisms are >>> located in L2 and other mechanisms are located in L3. >>> Now, the different possible approaches vary greatly in their nature >>> and resulting capabilities. To understanding the benefits and >>> suitability of these alternatives, the requirements have to be >>> properly defined and understood. >>>=20 >>> The main goal of the BOF is understanding the need for work in the >>> IETF in this area. In order to do so, during the BOF, we will attempt t= o: >>>=20 >>> 1) Understand the applicable scenarios, and the problem statement relat= ed >>> to >>> those >>> 2) Understand the restrictions and requirement imposed to solutions to >>> address the problem statement and scenarios >>> 3) Get an overview of the proposed solutions >>>=20 >>>=20 >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/netlmm >>=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From xiayangsong@huawei.com Mon Jun 29 14:36:34 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AE4228C305; Mon, 29 Jun 2009 14:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, STOX_REPLY_TYPE=0.001] 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 HP8lrir3OhZP; Mon, 29 Jun 2009 14:36:33 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CC7663A6C27; Mon, 29 Jun 2009 14:36:32 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM000M7PS0OKE@szxga04-in.huawei.com>; Tue, 30 Jun 2009 05:36:24 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM000KDMS0O5T@szxga04-in.huawei.com>; Tue, 30 Jun 2009 05:36:24 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM0002VYS0K4M@szxml04-in.huawei.com>; Tue, 30 Jun 2009 05:36:24 +0800 (CST) Date: Mon, 29 Jun 2009 16:36:20 -0500 From: Frank Xia To: Basavaraj.Patil@nokia.com, marcelo@it.uc3m.es, netext@ietf.org, mext@ietf.org, netlmm@ietf.org Message-id: <00b701c9f901$a61c8420$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Cc: netext-chairs@tools.ietf.org Subject: Re: [MEXT] [netext] [netlmm] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 21:36:34 -0000 Hi Raj IMHO Make-before-break is not a link-layer technology. , but a concept (or a strategy). Related to the topic we are discussing, making target interface ready before moving traffic to it is kind of make-before-break. BR Frank ----- Original Message ----- From: To: ; ; ; ; Cc: ; Sent: Monday, June 29, 2009 3:43 PM Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof description Hi Frank, Comments inline: On 6/29/09 2:57 PM, "ext Frank Xia" wrote: > Hi Raj > > My main point is make-before-break strategy > is the best way to solve multi-radio handover. The IETF cannot do anything about whether an MN has the ability to accomplish make-before-break connectivity. It depends on the link-layer technology, spectrum that they operate in, etc. So this approach is a non-starter. The IETF solution has to be agnostic to underlying access technologies. > > Please see my inline response. > > BR > ----- Original Message ----- > From: > To: ; ; ; > ; > Cc: ; > Sent: Monday, June 29, 2009 11:50 AM > Subject: Re: [netlmm] NEXTEXT2: first draft of the bof description > > > > Frank, > > > On 6/29/09 11:16 AM, "ext Frank Xia" wrote: > >> Hi Guys >> >> I have comments on inter-technology handover. >> >> IMHO, flow mobility could solve problems >> which inter-tech handover is try to deal with. > > Flow mobility also includes the ability to move a flow from one mobility > session to another. Multiple mobility sessions could be established via a > single interface in which case flow mobility would be achieved within the > scope of a single interface. Hence flow mobility and inter-technology > handovers are separate features. > Frank=>IMHO, inter-technology is trying to move all the traffic on > one interface to another interface. Right. I guess you answered the question about the difference between flow mobility and inter-technology handovers. You could extrapolate and say that inter-technology HO is the case where you move all flows from one interface to another and hence a variant of flow mobility. While that is true, you should also recognize that the granularity of flow mobility is finer and does not have to necessarily be a relocation of a flow between physical interfaces. > >> I assume that two heterogeneous interfaces are >> all active during the handover. It is easy to move >> a flow(or all flows) from an interface to another. > > Possibly.. But the point is to identify what extensions (possibly to the > MN) > are needed in order to achieve handovers across interfaces. > Frank=>If we see inter-tech handover as a subset of flow mobility, > there is one problem left, that is flow mobility. See above. Flow mobility is a feature that can work across multiple mobility sessions within the scope of a single interface as well. > >> >> This is probably the reason why there is no >> inter-tech handover solution standerdized >> for client MIP. > > Client MIP inherently supports handovers across multiple interfaces. > Performance improvements to the handovers are accomplished using solutions > such as FMIP. > Frank=>Maybe, I am missing something. However FMIP is not applicable > to PAR/NAR collocated scenario. For example, a mobile node with two > interface connects to the same access router (ASN-GW for WiMAX, > PDN-GW for LTE). Does FMIP work when mobile node handover from > one technology to another? Not sure I understand the question. In your example above, I believe the MN would connect to the ASN-GW via the WiMAX interface and to an S-GW via the LTE interface. The P-GW (LMA) may be the same. If the question is, can you use FMIP to optimize handovers in such a scenario... Yes. Not FMIP, but PFMIP6 (ref. MIPSHOP WG I-D). But I don't think we are looking at optimizing handovers in this discussion. As per the current PMIP6 specification wherein no changes to the host are required, it is not possible to do an inter-technology handover. This is a limitation which implies that PMIP6 provides host mobility to an MN within the scope of a single access technology. Host based mobile IP does not have this problem. -Raj > > -Raj > >> >> BR >> Frank >> >> ----- Original Message ----- >> From: "marcelo bagnulo braun" >> To: ; "mext" ; >> Cc: ; "Ralph Droms" >> Sent: Sunday, June 28, 2009 1:16 PM >> Subject: [netlmm] NEXTEXT2: first draft of the bof description >> >> >>> Hi, >>> >>> This is a first draft of the BOF description for your consideration. It >>> is >>> still very open so, feel free to comment on whether the proposed >>> approach >>> seems appropriate or not. >>> >>> NETEXT2 BOF description >>> ----------------------- >>> >>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility >>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to >>> IP hosts without requiring any protocol enhancements or additional >>> capabilities on the host. >>> Current PMIP6 specification fully defines how to provide mobility >>> support for mobile nodes with a single interface roaming in a PMIP6 >>> domain. The goal of this BOF is gain understanding of how to support >>> nodes with multiple interfaces (of possible different technologies) in a >>> PMIP6 network. >>> >>> In particular, this BOF assumes the following scenario: >>> We have a single PMIP6 domain that has deployed multiple >>> access technologies and needs to support nodes that have >>> multiple interfaces, possibly of different technologies. >>> >>> In particular, the following capabilities are needed: >>> >>> - Inter-technology handover support. The MN has initiated a >>> communication over one interface and it needs to be able to move >>> the established connection to a different interface of >>> a possibly different technology. The reason for moving >>> the communication to another interface is because of the MNs >>> mobility and attaching via a different interface. Basically >>> the ability to perform handovers that span different access >>> technologies. >>> >>> - Multihoming support. The MN with multiple interfaces of possibly >>> different technologies should be able to use them simultaneously to >>> exchange data and manage the mobility of communications >>> established through the different interfaces. >>> >>> - Flow mobility. A MN with multiple interfaces of possibly >>> different technologies must be able to move a flow from >>> one interface to another. Moreover, the MN should be able >>> to inform the network through which interface it wishes >>> to receive different types of flows. >>> >>> In order to provide the support for these capabilities, different >>> approaches can be envisioned, namely: >>> - L2 only approaches. In this type of approaches, the mechanisms >>> to provide the required capabilities are fully L2 mechanisms and >>> no modification of the IP layer is needed. >>> - L3 only approaches. In this type of approaches, the mechanism to >>> provide to required capabilities are located in the IP layer >>> - Hybrid L2/L3 approaches. In this case, some mechanisms are >>> located in L2 and other mechanisms are located in L3. >>> Now, the different possible approaches vary greatly in their nature >>> and resulting capabilities. To understanding the benefits and >>> suitability of these alternatives, the requirements have to be >>> properly defined and understood. >>> >>> The main goal of the BOF is understanding the need for work in the >>> IETF in this area. In order to do so, during the BOF, we will attempt >>> to: >>> >>> 1) Understand the applicable scenarios, and the problem statement >>> related >>> to >>> those >>> 2) Understand the restrictions and requirement imposed to solutions to >>> address the problem statement and scenarios >>> 3) Get an overview of the proposed solutions >>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/netlmm >> > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Mon Jun 29 15:29:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF4783A6C05; Mon, 29 Jun 2009 15:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.202 X-Spam-Level: X-Spam-Status: No, score=-6.202 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] 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 Dw7pVn0rI2aL; Mon, 29 Jun 2009 15:29:12 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id DDF4E3A6B64; Mon, 29 Jun 2009 15:29:06 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5TMT1Pw023455; Tue, 30 Jun 2009 01:29:07 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Jun 2009 01:28:55 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Jun 2009 01:28:50 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 30 Jun 2009 00:28:49 +0200 From: To: , , , , Date: Tue, 30 Jun 2009 00:28:57 +0200 Thread-Topic: [netext] [netlmm] NEXTEXT2: first draft of the bof description Thread-Index: Acn5Aay986hKNg67SFaq1F9+Bv5PQAAB1ERK Message-ID: In-Reply-To: <00b701c9f901$a61c8420$3e0c7c0a@china.huawei.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jun 2009 22:28:50.0175 (UTC) FILETIME=[F9BD30F0:01C9F908] X-Nokia-AV: Clean Cc: netext-chairs@tools.ietf.org Subject: Re: [MEXT] [netext] [netlmm] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 22:29:14 -0000 Hi Frank, Make-before-break is inherently supported in certain technologies such as CDMA/WCDMA (which has soft HO features built in). The same is not possible for example in TDMA (GSM) or OFDMA (802.16e and WiFi). 802.16e does have a contorted mechansim for achieving the same but that's besides the point. So IMO it is a capability of the Phy/Mac. However it is possible to emulate soft-handovers and achieve make-before-break in certain cases. For example it is possible to be simultaneously connected to HSPA and WiFi and accomplish a make-before-brea= k HO. I guess the definition of the term depends on an access tchnology or th= e combination of access technologies in the context of a use-case. -Raj On 6/29/09 4:36 PM, "ext Frank Xia" wrote: > Hi Raj >=20 > IMHO Make-before-break is not a link-layer technology. > , but a concept (or a strategy). Related to the topic we > are discussing, making target interface ready before moving > traffic to it is kind of make-before-break. >=20 > BR > Frank >=20 > ----- Original Message ----- > From: > To: ; ; ; > ; > Cc: ; > Sent: Monday, June 29, 2009 3:43 PM > Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof descripti= on >=20 >=20 >=20 > Hi Frank, >=20 > Comments inline: >=20 >=20 > On 6/29/09 2:57 PM, "ext Frank Xia" wrote: >=20 >> Hi Raj >>=20 >> My main point is make-before-break strategy >> is the best way to solve multi-radio handover. >=20 > The IETF cannot do anything about whether an MN has the ability to > accomplish make-before-break connectivity. It depends on the link-layer > technology, spectrum that they operate in, etc. So this approach is a > non-starter. The IETF solution has to be agnostic to underlying access > technologies. >=20 >>=20 >> Please see my inline response. >>=20 >> BR >> ----- Original Message ----- >> From: >> To: ; ; ; >> ; >> Cc: ; >> Sent: Monday, June 29, 2009 11:50 AM >> Subject: Re: [netlmm] NEXTEXT2: first draft of the bof description >>=20 >>=20 >>=20 >> Frank, >>=20 >>=20 >> On 6/29/09 11:16 AM, "ext Frank Xia" wrote: >>=20 >>> Hi Guys >>>=20 >>> I have comments on inter-technology handover. >>>=20 >>> IMHO, flow mobility could solve problems >>> which inter-tech handover is try to deal with. >>=20 >> Flow mobility also includes the ability to move a flow from one mobility >> session to another. Multiple mobility sessions could be established via = a >> single interface in which case flow mobility would be achieved within th= e >> scope of a single interface. Hence flow mobility and inter-technology >> handovers are separate features. >> Frank=3D>IMHO, inter-technology is trying to move all the traffic on >> one interface to another interface. >=20 > Right. I guess you answered the question about the difference between flo= w > mobility and inter-technology handovers. You could extrapolate and say th= at > inter-technology HO is the case where you move all flows from one interfa= ce > to another and hence a variant of flow mobility. While that is true, you > should also recognize that the granularity of flow mobility is finer and > does not have to necessarily be a relocation of a flow between physical > interfaces. >>=20 >>> I assume that two heterogeneous interfaces are >>> all active during the handover. It is easy to move >>> a flow(or all flows) from an interface to another. >>=20 >> Possibly.. But the point is to identify what extensions (possibly to the >> MN) >> are needed in order to achieve handovers across interfaces. >> Frank=3D>If we see inter-tech handover as a subset of flow mobility, >> there is one problem left, that is flow mobility. >=20 > See above. Flow mobility is a feature that can work across multiple mobil= ity > sessions within the scope of a single interface as well. >=20 >>=20 >>>=20 >>> This is probably the reason why there is no >>> inter-tech handover solution standerdized >>> for client MIP. >>=20 >> Client MIP inherently supports handovers across multiple interfaces. >> Performance improvements to the handovers are accomplished using solutio= ns >> such as FMIP. >> Frank=3D>Maybe, I am missing something. However FMIP is not applicable >> to PAR/NAR collocated scenario. For example, a mobile node with two >> interface connects to the same access router (ASN-GW for WiMAX, >> PDN-GW for LTE). Does FMIP work when mobile node handover from >> one technology to another? >=20 > Not sure I understand the question. In your example above, I believe the = MN > would connect to the ASN-GW via the WiMAX interface and to an S-GW via th= e > LTE interface. The P-GW (LMA) may be the same. If the question is, can yo= u > use FMIP to optimize handovers in such a scenario... Yes. Not FMIP, but > PFMIP6 (ref. MIPSHOP WG I-D). But I don't think we are looking at optimiz= ing > handovers in this discussion. > As per the current PMIP6 specification wherein no changes to the host are > required, it is not possible to do an inter-technology handover. This is = a > limitation which implies that PMIP6 provides host mobility to an MN withi= n > the scope of a single access technology. Host based mobile IP does not ha= ve > this problem. >=20 > -Raj >=20 >>=20 >> -Raj >>=20 >>>=20 >>> BR >>> Frank >>>=20 >>> ----- Original Message ----- >>> From: "marcelo bagnulo braun" >>> To: ; "mext" ; >>> Cc: ; "Ralph Droms" >>> Sent: Sunday, June 28, 2009 1:16 PM >>> Subject: [netlmm] NEXTEXT2: first draft of the bof description >>>=20 >>>=20 >>>> Hi, >>>>=20 >>>> This is a first draft of the BOF description for your consideration. I= t >>>> is >>>> still very open so, feel free to comment on whether the proposed >>>> approach >>>> seems appropriate or not. >>>>=20 >>>> NETEXT2 BOF description >>>> ----------------------- >>>>=20 >>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility >>>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to >>>> IP hosts without requiring any protocol enhancements or additional >>>> capabilities on the host. >>>> Current PMIP6 specification fully defines how to provide mobility >>>> support for mobile nodes with a single interface roaming in a PMIP6 >>>> domain. The goal of this BOF is gain understanding of how to support >>>> nodes with multiple interfaces (of possible different technologies) in= a >>>> PMIP6 network. >>>>=20 >>>> In particular, this BOF assumes the following scenario: >>>> We have a single PMIP6 domain that has deployed multiple >>>> access technologies and needs to support nodes that have >>>> multiple interfaces, possibly of different technologies. >>>>=20 >>>> In particular, the following capabilities are needed: >>>>=20 >>>> - Inter-technology handover support. The MN has initiated a >>>> communication over one interface and it needs to be able to move >>>> the established connection to a different interface of >>>> a possibly different technology. The reason for moving >>>> the communication to another interface is because of the MNs >>>> mobility and attaching via a different interface. Basically >>>> the ability to perform handovers that span different access >>>> technologies. >>>>=20 >>>> - Multihoming support. The MN with multiple interfaces of possibly >>>> different technologies should be able to use them simultaneously to >>>> exchange data and manage the mobility of communications >>>> established through the different interfaces. >>>>=20 >>>> - Flow mobility. A MN with multiple interfaces of possibly >>>> different technologies must be able to move a flow from >>>> one interface to another. Moreover, the MN should be able >>>> to inform the network through which interface it wishes >>>> to receive different types of flows. >>>>=20 >>>> In order to provide the support for these capabilities, different >>>> approaches can be envisioned, namely: >>>> - L2 only approaches. In this type of approaches, the mechanisms >>>> to provide the required capabilities are fully L2 mechanisms and >>>> no modification of the IP layer is needed. >>>> - L3 only approaches. In this type of approaches, the mechanism to >>>> provide to required capabilities are located in the IP layer >>>> - Hybrid L2/L3 approaches. In this case, some mechanisms are >>>> located in L2 and other mechanisms are located in L3. >>>> Now, the different possible approaches vary greatly in their nature >>>> and resulting capabilities. To understanding the benefits and >>>> suitability of these alternatives, the requirements have to be >>>> properly defined and understood. >>>>=20 >>>> The main goal of the BOF is understanding the need for work in the >>>> IETF in this area. In order to do so, during the BOF, we will attempt >>>> to: >>>>=20 >>>> 1) Understand the applicable scenarios, and the problem statement >>>> related >>>> to >>>> those >>>> 2) Understand the restrictions and requirement imposed to solutions to >>>> address the problem statement and scenarios >>>> 3) Get an overview of the proposed solutions >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netlmm mailing list >>>> netlmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netlmm >>>=20 >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >=20 From trac@tools.ietf.org Mon Jun 29 16:16:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531453A6B3E for ; Mon, 29 Jun 2009 16:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 RIyXs-UnBQso for ; Mon, 29 Jun 2009 16:16:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 83D743A6AAE for ; Mon, 29 Jun 2009 16:16:13 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MLQ5S-0004Up-Ik; Mon, 29 Jun 2009 16:16:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "Mext Issue Tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Mon, 29 Jun 2009 23:16:34 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mext/trac/ticket/18#comment:1 Message-ID: <066.53fe240dcb94a6ca110a4ff44d9b75c0@tools.ietf.org> References: <057.593245298a70f232e7c46117adba47bb@tools.ietf.org> X-Trac-Ticket-ID: 18 In-Reply-To: <057.593245298a70f232e7c46117adba47bb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #18: Subject: Issues regarding Home Address Option & ICMP / Binding errors X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 23:16:14 -0000 #18: Subject: Issues regarding Home Address Option & ICMP / Binding errors ----------------------------------------+----------------------------------- Reporter: f1mauchl@hsr.ch | Owner: charliep@computer.org Type: defect | Status: assigned Priority: major | Milestone: IETF75 Component: draft-ietf-mext-rfc3775bis | Version: 4.0 Severity: Active WG Document | Resolution: Keywords: Home Address Option | ----------------------------------------+----------------------------------- Changes (by charliep@computer.org): * keywords: => Home Address Option * owner: => charliep@computer.org * version: => 4.0 * status: new => assigned * milestone: => IETF75 Comment: I propose to resolve this issue by accepting the suggested text, which should not materially impact any compliant implementations. ================================================ The issue (and proposed resolution): >> In Section 9.3.1. Receiving Packets with Home Address Option: >> "Packets containing a Home Address option MUST be dropped if >> there is no corresponding Binding Cache entry. (...) These >> tests MUST NOT be done for packets that contain a Home Address >> option and a Binding Update." >> >> The second part of this statement (packets that contain a Home >> Address option and a Binding Update) requires looking ahead in >> the packet for a Mobility Header with a respective type. This >> action is stricly forbidden by IPv6 ... >> .......... Changes to the second paragraph in 9.3.1: >> Mobile nodes can include a Home Address destination option in a >> packet if they believe the correspondent node has a Binding Cache >> entry for the home address of a mobile node. If the Next Header >> value of the Destination Option is one of the following: {50 (ESP), >> 51 (AH), 135 (Mobility Header)}, the packet SHOULD be processed >> normally. Else, the packet MUST be dropped if there is no >> corresponding Binding Cache entry. A corresponding Binding Cache >> entry MUST have the same home address as appears in the Home Address >> destination option, and the currently registered care-of address >> MUST be equal to the source address of the packet. >> The assumption about looking ahead in the packet is not correct, I've >> implemented this without doing it :) Since a HAO isn't mandatory in all >> BU's (deletion for example), that processing code just needs to know if >> one was seen previously - if not the packet could be silently dropped. >> The response from Brian Haley points out that the processing can be done without violating this restriction: >> 1. When processing the HAO, you need to do a binding cache lookup to >> validate it. You can "remember" whether you found an entry, and whether >> you swapped the address. You need to continue to process it... >> >> 2. When processing the MH, you can consult the saved saved information from >> step #1 - did I see a HAO? but then subsequently agrees with the proposed modification to section 9.3.1: >> I think the <... proposed text ...> >> ... is fine. I don't think any other next header types would be valid. ================================================ -- Ticket URL: mext From hesham@elevatemobile.com Mon Jun 29 17:12:10 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5765F3A6A89; Mon, 29 Jun 2009 17:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=-1.458, BAYES_50=0.001] 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 S-E4+qvH--+F; Mon, 29 Jun 2009 17:12:09 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 934CD3A6927; Mon, 29 Jun 2009 17:12:08 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MLQxW-0007Z6-W5; Tue, 30 Jun 2009 10:12:27 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 30 Jun 2009 10:12:19 +1000 From: Hesham Soliman To: Message-ID: Thread-Topic: Cross posting Thread-Index: Acn5F2581YkmsRcwh0eDxPYkagxsmQ== In-Reply-To: <001401c9f8dd$d6c16830$3e0c7c0a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: netlmm@ietf.org, netext-chairs@tools.ietf.org, mext Subject: [MEXT] Cross posting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 00:12:10 -0000 It would be nice if postings are limited to one mailing list please! Hesham From charles.perkins@earthlink.net Mon Jun 29 17:43:22 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5489C3A6A89; Mon, 29 Jun 2009 17:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6] 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 XGgHOMxjEgk3; Mon, 29 Jun 2009 17:43:21 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id DDC5A3A69D2; Mon, 29 Jun 2009 17:43:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=uA84kz6wDJumXee8oiw2Jy6M7lYycqDck0XP4ZkZWIqeicv+oqf8rn9e5dCY1Pdf; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.108]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MLRRl-0003Zs-Cb; Mon, 29 Jun 2009 20:43:41 -0400 Message-ID: <4A495FBB.9090106@earthlink.net> Date: Mon, 29 Jun 2009 17:43:39 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5214befd3ba834d4c63b46399306177a1f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: "netlmm@ietf.org" , mext Subject: Re: [MEXT] [netext] [netlmm] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 00:43:22 -0000 Hello Basavaraj, Isn't make-before-break a function performed at the link layer? It certainly isn't PHY, and I wouldn't think it qualifies as MAC (i.e., it doesn't control the device's access to the medium). Regards, Charlie P. PS. Which is the proper mailing list for this discussion? Basavaraj.Patil@nokia.com wrote: > Hi Frank, > > Make-before-break is inherently supported in certain technologies such as > CDMA/WCDMA (which has soft HO features built in). The same is not possible > for example in TDMA (GSM) or OFDMA (802.16e and WiFi). 802.16e does have a > contorted mechansim for achieving the same but that's besides the point. > So IMO it is a capability of the Phy/Mac. > However it is possible to emulate soft-handovers and achieve > make-before-break in certain cases. For example it is possible to be > simultaneously connected to HSPA and WiFi and accomplish a make-before-break > HO. I guess the definition of the term depends on an access tchnology or the > combination of access technologies in the context of a use-case. > > -Raj > > > On 6/29/09 4:36 PM, "ext Frank Xia" wrote: > > >> Hi Raj >> >> IMHO Make-before-break is not a link-layer technology. >> , but a concept (or a strategy). Related to the topic we >> are discussing, making target interface ready before moving >> traffic to it is kind of make-before-break. >> >> BR >> Frank >> >> ----- Original Message ----- >> From: >> To: ; ; ; >> ; >> Cc: ; >> Sent: Monday, June 29, 2009 3:43 PM >> Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof description >> >> >> >> Hi Frank, >> >> Comments inline: >> >> >> On 6/29/09 2:57 PM, "ext Frank Xia" wrote: >> >> >>> Hi Raj >>> >>> My main point is make-before-break strategy >>> is the best way to solve multi-radio handover. >>> >> The IETF cannot do anything about whether an MN has the ability to >> accomplish make-before-break connectivity. It depends on the link-layer >> technology, spectrum that they operate in, etc. So this approach is a >> non-starter. The IETF solution has to be agnostic to underlying access >> technologies. >> >> >>> Please see my inline response. >>> >>> BR >>> ----- Original Message ----- >>> From: >>> To: ; ; ; >>> ; >>> Cc: ; >>> Sent: Monday, June 29, 2009 11:50 AM >>> Subject: Re: [netlmm] NEXTEXT2: first draft of the bof description >>> >>> >>> >>> Frank, >>> >>> >>> On 6/29/09 11:16 AM, "ext Frank Xia" wrote: >>> >>> >>>> Hi Guys >>>> >>>> I have comments on inter-technology handover. >>>> >>>> IMHO, flow mobility could solve problems >>>> which inter-tech handover is try to deal with. >>>> >>> Flow mobility also includes the ability to move a flow from one mobility >>> session to another. Multiple mobility sessions could be established via a >>> single interface in which case flow mobility would be achieved within the >>> scope of a single interface. Hence flow mobility and inter-technology >>> handovers are separate features. >>> Frank=>IMHO, inter-technology is trying to move all the traffic on >>> one interface to another interface. >>> >> Right. I guess you answered the question about the difference between flow >> mobility and inter-technology handovers. You could extrapolate and say that >> inter-technology HO is the case where you move all flows from one interface >> to another and hence a variant of flow mobility. While that is true, you >> should also recognize that the granularity of flow mobility is finer and >> does not have to necessarily be a relocation of a flow between physical >> interfaces. >> >>>> I assume that two heterogeneous interfaces are >>>> all active during the handover. It is easy to move >>>> a flow(or all flows) from an interface to another. >>>> >>> Possibly.. But the point is to identify what extensions (possibly to the >>> MN) >>> are needed in order to achieve handovers across interfaces. >>> Frank=>If we see inter-tech handover as a subset of flow mobility, >>> there is one problem left, that is flow mobility. >>> >> See above. Flow mobility is a feature that can work across multiple mobility >> sessions within the scope of a single interface as well. >> >> >>>> This is probably the reason why there is no >>>> inter-tech handover solution standerdized >>>> for client MIP. >>>> >>> Client MIP inherently supports handovers across multiple interfaces. >>> Performance improvements to the handovers are accomplished using solutions >>> such as FMIP. >>> Frank=>Maybe, I am missing something. However FMIP is not applicable >>> to PAR/NAR collocated scenario. For example, a mobile node with two >>> interface connects to the same access router (ASN-GW for WiMAX, >>> PDN-GW for LTE). Does FMIP work when mobile node handover from >>> one technology to another? >>> >> Not sure I understand the question. In your example above, I believe the MN >> would connect to the ASN-GW via the WiMAX interface and to an S-GW via the >> LTE interface. The P-GW (LMA) may be the same. If the question is, can you >> use FMIP to optimize handovers in such a scenario... Yes. Not FMIP, but >> PFMIP6 (ref. MIPSHOP WG I-D). But I don't think we are looking at optimizing >> handovers in this discussion. >> As per the current PMIP6 specification wherein no changes to the host are >> required, it is not possible to do an inter-technology handover. This is a >> limitation which implies that PMIP6 provides host mobility to an MN within >> the scope of a single access technology. Host based mobile IP does not have >> this problem. >> >> -Raj >> >> >>> -Raj >>> >>> >>>> BR >>>> Frank >>>> >>>> ----- Original Message ----- >>>> From: "marcelo bagnulo braun" >>>> To: ; "mext" ; >>>> Cc: ; "Ralph Droms" >>>> Sent: Sunday, June 28, 2009 1:16 PM >>>> Subject: [netlmm] NEXTEXT2: first draft of the bof description >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> This is a first draft of the BOF description for your consideration. It >>>>> is >>>>> still very open so, feel free to comment on whether the proposed >>>>> approach >>>>> seems appropriate or not. >>>>> >>>>> NETEXT2 BOF description >>>>> ----------------------- >>>>> >>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility >>>>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to >>>>> IP hosts without requiring any protocol enhancements or additional >>>>> capabilities on the host. >>>>> Current PMIP6 specification fully defines how to provide mobility >>>>> support for mobile nodes with a single interface roaming in a PMIP6 >>>>> domain. The goal of this BOF is gain understanding of how to support >>>>> nodes with multiple interfaces (of possible different technologies) in a >>>>> PMIP6 network. >>>>> >>>>> In particular, this BOF assumes the following scenario: >>>>> We have a single PMIP6 domain that has deployed multiple >>>>> access technologies and needs to support nodes that have >>>>> multiple interfaces, possibly of different technologies. >>>>> >>>>> In particular, the following capabilities are needed: >>>>> >>>>> - Inter-technology handover support. The MN has initiated a >>>>> communication over one interface and it needs to be able to move >>>>> the established connection to a different interface of >>>>> a possibly different technology. The reason for moving >>>>> the communication to another interface is because of the MNs >>>>> mobility and attaching via a different interface. Basically >>>>> the ability to perform handovers that span different access >>>>> technologies. >>>>> >>>>> - Multihoming support. The MN with multiple interfaces of possibly >>>>> different technologies should be able to use them simultaneously to >>>>> exchange data and manage the mobility of communications >>>>> established through the different interfaces. >>>>> >>>>> - Flow mobility. A MN with multiple interfaces of possibly >>>>> different technologies must be able to move a flow from >>>>> one interface to another. Moreover, the MN should be able >>>>> to inform the network through which interface it wishes >>>>> to receive different types of flows. >>>>> >>>>> In order to provide the support for these capabilities, different >>>>> approaches can be envisioned, namely: >>>>> - L2 only approaches. In this type of approaches, the mechanisms >>>>> to provide the required capabilities are fully L2 mechanisms and >>>>> no modification of the IP layer is needed. >>>>> - L3 only approaches. In this type of approaches, the mechanism to >>>>> provide to required capabilities are located in the IP layer >>>>> - Hybrid L2/L3 approaches. In this case, some mechanisms are >>>>> located in L2 and other mechanisms are located in L3. >>>>> Now, the different possible approaches vary greatly in their nature >>>>> and resulting capabilities. To understanding the benefits and >>>>> suitability of these alternatives, the requirements have to be >>>>> properly defined and understood. >>>>> >>>>> The main goal of the BOF is understanding the need for work in the >>>>> IETF in this area. In order to do so, during the BOF, we will attempt >>>>> to: >>>>> >>>>> 1) Understand the applicable scenarios, and the problem statement >>>>> related >>>>> to >>>>> those >>>>> 2) Understand the restrictions and requirement imposed to solutions to >>>>> address the problem statement and scenarios >>>>> 3) Get an overview of the proposed solutions >>>>> >>>>> >>>>> _______________________________________________ >>>>> netlmm mailing list >>>>> netlmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netlmm >>>>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > From stu.card@critical.com Mon Jun 29 18:18:17 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C37C3A6C88; Mon, 29 Jun 2009 18:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 hDzPMAmKhACx; Mon, 29 Jun 2009 18:18:16 -0700 (PDT) Received: from mail.critical.com (mail.critical.com [64.246.137.41]) by core3.amsl.com (Postfix) with ESMTP id 0918828C194; Mon, 29 Jun 2009 18:18:15 -0700 (PDT) Received: by mail.critical.com (Postfix, from userid 99) id B1A3338012; Mon, 29 Jun 2009 21:18:35 -0400 (EDT) Received: from [192.168.10.103] (unknown [64.246.137.24]) by mail.critical.com (Postfix) with ESMTP id 1EB7049B8; Mon, 29 Jun 2009 21:18:32 -0400 (EDT) Message-ID: <4A4967E6.30308@critical.com> Date: Mon, 29 Jun 2009 21:18:30 -0400 From: "Stuart W. Card" Organization: Critical Technologies Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mext References: <4A495FBB.9090106@earthlink.net> In-Reply-To: <4A495FBB.9090106@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netlmm@ietf.org" , Basavaraj.Patil@nokia.com Subject: Re: [MEXT] [netext] [netlmm] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 01:18:17 -0000 Charles E. Perkins wrote: > Isn't make-before-break a function performed > at the link layer? > > It certainly isn't PHY, and I wouldn't think it > qualifies as MAC (i.e., it doesn't control the > device's access to the medium). Different approaches to make-before-break can be implemented in different layers. For several years, our team has done it at Layer 3, because we have had the luxury of multiple radios that can operate concurrently. We simply make a MIP registration on every radio that policy says we are allowed to use at the moment and that can hear a base station, and insert concurrent multipath routes into our routing table. Traffic naturally gets divided among paths, which we weight according to their recent performance, so as a link fades, less and less traffic is routed over that path, and eventually we drop it from the routing table (generally when we can no longer successfully renew our MIP registration over it). This is fairly trivial if the load balancing is flow-by-flow. If it is packet-by-packet, then most TCP implementations will blow up, so we use the SCPS-TP variant. My point is not that everyone should use SCPS-TP over Concurrent Multipath Routing, but that make-before-break is a cat that can be skinned many ways, depending upon what you are making and breaking: a physical channel; a logical link; an end-to-end path; etc. -- Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 www.critical.com From gwz@net-zen.net Mon Jun 29 19:06:06 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086303A6C29 for ; Mon, 29 Jun 2009 19:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.490, 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 4Jnnckk3o0x5 for ; Mon, 29 Jun 2009 19:06:05 -0700 (PDT) Received: from smtpout08.prod.mesa1.secureserver.net (smtpout08-01.prod.mesa1.secureserver.net [64.202.165.119]) by core3.amsl.com (Postfix) with SMTP id 18DC13A6A49 for ; Mon, 29 Jun 2009 19:06:04 -0700 (PDT) Received: (qmail 24737 invoked from network); 30 Jun 2009 02:06:25 -0000 Received: from unknown (124.121.210.22) by smtpout08.prod.mesa1.secureserver.net (64.202.165.119) with ESMTP; 30 Jun 2009 02:06:25 -0000 From: "Glen Zorn" To: , References: <00b701c9f901$a61c8420$3e0c7c0a@china.huawei.com> In-Reply-To: Date: Tue, 30 Jun 2009 09:02:30 +0700 Organization: Network Zen Message-ID: <016901c9f926$d6afaac0$840f0040$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn5Aay986hKNg67SFaq1F9+Bv5PQAAB1ERKAAcyqUA= Content-Language: en-us Cc: netext@ietf.org, netlmm@ietf.org, netext-chairs@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] [netext] [netlmm] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 02:06:06 -0000 Basavaraj.Patil@nokia.com writes: > Hi Frank, > > Make-before-break is inherently supported in certain technologies such > as > CDMA/WCDMA (which has soft HO features built in). The same is not > possible > for example in TDMA (GSM) or OFDMA (802.16e and WiFi). 802.16e does > have a > contorted mechansim for achieving the same but that's besides the > point. > So IMO it is a capability of the Phy/Mac. > However it is possible to emulate soft-handovers and achieve > make-before-break in certain cases. For example it is possible to be > simultaneously connected to HSPA and WiFi and accomplish a make-before- > break > HO. I guess the definition of the term depends on an access tchnology > or the > combination of access technologies in the context of a use-case. I'm inclined to agree with you, though isn't the implementation of make-before-break capability possible using any PHY & dual radios? The problem being the price of parts... ... From marcelo@it.uc3m.es Tue Jun 30 02:34:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9283A6A7B for ; Tue, 30 Jun 2009 02:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 GvSCeGLOHzGo for ; Tue, 30 Jun 2009 02:34:19 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 5D8E33A68EA for ; Tue, 30 Jun 2009 02:34:18 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap003.it.uc3m.es [163.117.139.45]) by smtp01.uc3m.es (Postfix) with ESMTP id 4AA10BA21B4; Tue, 30 Jun 2009 10:24:44 +0200 (CEST) Message-ID: <4A49CBCC.6090209@it.uc3m.es> Date: Tue, 30 Jun 2009 10:24:44 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mext@ietf.org References: <057.593245298a70f232e7c46117adba47bb@tools.ietf.org> <066.53fe240dcb94a6ca110a4ff44d9b75c0@tools.ietf.org> In-Reply-To: <066.53fe240dcb94a6ca110a4ff44d9b75c0@tools.ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16734.005 Cc: charliep@computer.org Subject: Re: [MEXT] [mext] #18: Subject: Issues regarding Home Address Option & ICMP / Binding errors X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 09:34:20 -0000 Please express your opinion on this before the sunday 5th of july. We hope to close the issue then and afaiu, we will have closed all the issues and we will be ready for WGLC Thanks, marcelo Mext Issue Tracker escribió: > #18: Subject: Issues regarding Home Address Option & ICMP / Binding errors > ----------------------------------------+----------------------------------- > Reporter: f1mauchl@hsr.ch | Owner: charliep@computer.org > Type: defect | Status: assigned > Priority: major | Milestone: IETF75 > Component: draft-ietf-mext-rfc3775bis | Version: 4.0 > Severity: Active WG Document | Resolution: > Keywords: Home Address Option | > ----------------------------------------+----------------------------------- > Changes (by charliep@computer.org): > > * keywords: => Home Address Option > * owner: => charliep@computer.org > * version: => 4.0 > * status: new => assigned > * milestone: => IETF75 > > > Comment: > > I propose to resolve > this issue by accepting the suggested text, which should > not materially impact any compliant implementations. > > ================================================ > > The issue (and proposed resolution): > > >> In Section 9.3.1. Receiving Packets with Home Address Option: > >> "Packets containing a Home Address option MUST be dropped if > >> there is no corresponding Binding Cache entry. (...) These > >> tests MUST NOT be done for packets that contain a Home Address > >> option and a Binding Update." > >> > >> The second part of this statement (packets that contain a Home > >> Address option and a Binding Update) requires looking ahead in > >> the packet for a Mobility Header with a respective type. This > >> action is stricly forbidden by IPv6 ... > > >> .......... Changes to the second paragraph in 9.3.1: > > >> Mobile nodes can include a Home Address destination option in a > >> packet if they believe the correspondent node has a Binding Cache > >> entry for the home address of a mobile node. If the Next Header > >> value of the Destination Option is one of the following: {50 (ESP), > >> 51 (AH), 135 (Mobility Header)}, the packet SHOULD be processed > >> normally. Else, the packet MUST be dropped if there is no > >> corresponding Binding Cache entry. A corresponding Binding Cache > >> entry MUST have the same home address as appears in the Home Address > >> destination option, and the currently registered care-of address > >> MUST be equal to the source address of the packet. > > > >> The assumption about looking ahead in the packet is not correct, I've > >> implemented this without doing it :) Since a HAO isn't mandatory in > all > >> BU's (deletion for example), that processing code just needs to know if > >> one was seen previously - if not the packet could be silently dropped. > >> > > The response from Brian Haley points out that the processing > can be done without violating this restriction: > > > >> 1. When processing the HAO, you need to do a binding cache lookup to > >> validate it. You can "remember" whether you found an entry, and > whether > >> you swapped the address. You need to continue to process it... > >> > >> 2. When processing the MH, you can consult the saved saved information > from > >> step #1 - did I see a HAO? > > but then subsequently agrees with the proposed modification to section > 9.3.1: > > >> I think the <... proposed text ...> > >> ... is fine. I don't think any other next header types would be valid. > > ================================================ > > From tsirtsis@googlemail.com Tue Jun 30 03:49:17 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5D828C393; Tue, 30 Jun 2009 03:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=-0.917, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6] 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 9HF-bMPL+t2q; Tue, 30 Jun 2009 03:49:16 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 3ED2828C394; Tue, 30 Jun 2009 03:49:15 -0700 (PDT) Received: by bwz9 with SMTP id 9so37723bwz.37 for ; Tue, 30 Jun 2009 03:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kLD1bMAl0rvM9wqQdiuXHOtRNHk+786eFkKCTO9DMl0=; b=QN3PZRHBXksyaLO2X3qf6dVIqbzsajcZ3SXrCSg38DwqDhBo38N45ZaASrS/tdMBuF XMKPtrtxubE6OQYrM2UQy6xYMj0C5Dmanqf9dZgnzP4nvGvbIBYyzTZ2XcCzmnur7XF3 VmpCVaGyfhDPXfermr2JJtnH6OBbOQ9svby1g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VZyQukCx2dzYLUSYdle0azW1qHITTy+zaKbeirYHkb2jC877JhfMsc1nnuYohscB1i Oz/Fdmw92I/VjfAn8erZ9zg4qzzyT+PdwjV4xak3bTxsW7zG5oNdKZdjMsb3nyM7MQBI o2/2gFbtcIvDxJp+sP/mC9/A/F3Q9PKgekwjQ= MIME-Version: 1.0 Received: by 10.223.107.199 with SMTP id c7mr5097202fap.31.1246358973363; Tue, 30 Jun 2009 03:49:33 -0700 (PDT) In-Reply-To: <4A495FBB.9090106@earthlink.net> References: <4A495FBB.9090106@earthlink.net> Date: Tue, 30 Jun 2009 11:49:33 +0100 Message-ID: From: George Tsirtsis To: "Charles E. Perkins" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext , "netlmm@ietf.org" , Basavaraj.Patil@nokia.com Subject: Re: [MEXT] [netext] [netlmm] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 10:49:17 -0000 Hi Charlie/Raj, et.al., In intra-technology handoffs, Make Before Break (MBB) is the ability of the given technology to acquire a connection to the new BS/sector while maintaining the connection to the existing BS/sector. CDMA sited as an example of technology capable of MBB, is maybe not the best one since the MBB functionality of CDMA is really at the PHY layer i.e., the MN maintains a single link to a BS-Controller type box over one or more PHY-layer connections to BSs. So this is PHY layer MBB. OFDMA on the other hand, at least as implemented in Flash-OFDM (a less known technology), is capable of implementing link layer MBB where an MN can create two independent link layer connections to two different BSs (in Flash-OFDM playing the role of MIPv4 FAs), but that seems to be an unusual case so far. Most technologies, seem to hide intra-technology handoff from the IP layer, and instead present a stable interface that to the IP layer it does not appear to be moving. So often, intra-technology handoffs of that kind (whether it is MBB or BBM) are transparent to the IETF. Inter-technology handoffs are a bit different. In some cases, such handoffs are still hidden from the IP layer, e.g., handoffs between 3GPP-specific technologies tends to be handled at lower layers. In other cases, however, such handoffs are visible to IP. This happens when each of the technology-specific interfaces present a different interface to the IP layer. In this case the interfaces tend to come up and down independently from each other (e.g., WLAN and 3G), but that is often also limited by the capabilities of the device e.g., a lot of devices can only transmit/receive over one radio at the time (strictly an implementation issue). People also often forget inter-domain handoffs. These, whether intra- or inter-technology, can also in some cases be visible to the IP layer. The bottom line is that at the *network layer* we should not be making too many assumptions about the capabilities of the lower layers. We should instead define generic mechanisms that can be widely applied, so for example, MIP+MCoA+FlowBindings, says nothing about MBB/BBM (and it says even less about inter/intra-technology/domain) and it works with all of the above. When I say it works, I mean the protocol is self-consistent in all of these cases, but obviously when you can only do BBM handoffs, MCoA and FlowBindings are not as useful; which is fine. With PMIP things are not so clear....it is not even clear we are talking about the *network layer*... and thus it is not so clear how "generic" solutions can be. The challenge for the BOF is to throw some light on how PMIP can be compatible with this extended functionality, what type of additional signalling is needed, and at which layer they intend to implement such signalling. Let's see. George On Tue, Jun 30, 2009 at 1:43 AM, Charles E. Perkins wrote: > > Hello Basavaraj, > > Isn't make-before-break a function performed > at the link layer? > > It certainly isn't PHY, and I wouldn't think it > qualifies as MAC (i.e., it doesn't control the > device's access to the medium). > > Regards, > Charlie P. > > PS. Which is the proper mailing list for this discussion? > > Basavaraj.Patil@nokia.com wrote: >> >> Hi Frank, >> >> Make-before-break is inherently supported in certain technologies such a= s >> CDMA/WCDMA (which has soft HO features built in). The same is not possib= le >> for example in TDMA (GSM) or OFDMA (802.16e and WiFi). 802.16e does have= a >> contorted mechansim for achieving the same but that's besides the point. >> So IMO it is a capability of the Phy/Mac. >> However it is possible to emulate soft-handovers and achieve >> make-before-break in certain cases. For example it is possible to be >> simultaneously connected to HSPA and WiFi and accomplish a >> make-before-break >> HO. I guess the definition of the term depends on an access tchnology or >> the >> combination of access technologies in the context of a use-case. >> >> -Raj >> >> >> On 6/29/09 4:36 PM, "ext Frank Xia" wrote: >> >> >>> >>> Hi Raj >>> >>> IMHO Make-before-break is not a link-layer technology. >>> , but =C2=A0a concept (or a strategy). =C2=A0 =C2=A0Related to the topi= c we >>> are discussing, making target interface ready before moving >>> traffic to it is kind of make-before-break. >>> >>> BR >>> Frank >>> >>> ----- Original Message ----- >>> From: >>> To: ; ; ; >>> ; >>> Cc: ; >>> Sent: Monday, June 29, 2009 3:43 PM >>> Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof >>> description >>> >>> >>> >>> Hi Frank, >>> >>> Comments inline: >>> >>> >>> On 6/29/09 2:57 PM, "ext Frank Xia" wrote: >>> >>> >>>> >>>> Hi Raj >>>> >>>> My main point is make-before-break strategy >>>> is the best way to solve multi-radio handover. >>>> >>> >>> The IETF cannot do anything about whether an MN has the ability to >>> accomplish make-before-break connectivity. It depends on the link-layer >>> technology, spectrum that they operate in, etc. So this approach is a >>> non-starter. The IETF solution has to be agnostic to underlying access >>> technologies. >>> >>> >>>> >>>> Please see my inline response. >>>> >>>> BR >>>> ----- Original Message ----- >>>> From: >>>> To: ; ; ; >>>> ; >>>> Cc: ; >>>> Sent: Monday, June 29, 2009 11:50 AM >>>> Subject: Re: [netlmm] NEXTEXT2: first draft of the bof description >>>> >>>> >>>> >>>> Frank, >>>> >>>> >>>> On 6/29/09 11:16 AM, "ext Frank Xia" wrote: >>>> >>>> >>>>> >>>>> Hi Guys >>>>> >>>>> I have comments on inter-technology handover. >>>>> >>>>> IMHO, flow mobility could solve problems >>>>> which inter-tech handover is try to deal with. >>>>> >>>> >>>> Flow mobility also includes the ability to move a flow from one mobili= ty >>>> session to another. Multiple mobility sessions could be established vi= a >>>> a >>>> single interface in which case flow mobility would be achieved within >>>> the >>>> scope of a single interface. Hence flow mobility and inter-technology >>>> handovers are separate features. >>>> Frank=3D>IMHO, inter-technology is trying to move all the traffic on >>>> one interface to another interface. >>>> >>> >>> Right. I guess you answered the question about the difference between >>> flow >>> mobility and inter-technology handovers. You could extrapolate and say >>> that >>> inter-technology HO is the case where you move all flows from one >>> interface >>> to another and hence a variant of flow mobility. While that is true, yo= u >>> should also recognize that the granularity of flow mobility is finer an= d >>> does not have to necessarily be a relocation of a flow between physical >>> interfaces. >>> >>>>> >>>>> I assume that two heterogeneous interfaces are >>>>> all active during the handover. =C2=A0It is easy to move >>>>> a flow(or all flows) from an interface to another. >>>>> >>>> >>>> Possibly.. But the point is to identify what extensions (possibly to t= he >>>> MN) >>>> are needed in order to achieve handovers across interfaces. >>>> Frank=3D>If we see inter-tech handover as a subset of flow mobility, >>>> there is one problem left, that is flow mobility. >>>> >>> >>> See above. Flow mobility is a feature that can work across multiple >>> mobility >>> sessions within the scope of a single interface as well. >>> >>> >>>>> >>>>> This is probably the reason why there is no >>>>> inter-tech handover solution standerdized >>>>> for client MIP. >>>>> >>>> >>>> Client MIP inherently supports handovers across multiple interfaces. >>>> Performance improvements to the handovers are accomplished using >>>> solutions >>>> such as FMIP. >>>> Frank=3D>Maybe, I am missing something. =C2=A0However FMIP =C2=A0is no= t applicable >>>> to PAR/NAR collocated scenario. =C2=A0For example, a mobile node with = two >>>> interface connects to the same access router (ASN-GW for WiMAX, >>>> PDN-GW for LTE). =C2=A0 Does FMIP work when mobile node handover from >>>> one technology to another? >>>> >>> >>> Not sure I understand the question. In your example above, I believe th= e >>> MN >>> would connect to the ASN-GW via the WiMAX interface and to an S-GW via >>> the >>> LTE interface. The P-GW (LMA) may be the same. If the question is, can >>> you >>> use FMIP to optimize handovers in such a scenario... Yes. Not FMIP, but >>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't think we are looking at >>> optimizing >>> handovers in this discussion. >>> As per the current PMIP6 specification wherein no changes to the host a= re >>> required, it is not possible to do an inter-technology handover. This i= s >>> a >>> limitation which implies that PMIP6 provides host mobility to an MN >>> within >>> the scope of a single access technology. Host based mobile IP does not >>> have >>> this problem. >>> >>> -Raj >>> >>> >>>> >>>> -Raj >>>> >>>> >>>>> >>>>> BR >>>>> Frank >>>>> >>>>> ----- Original Message ----- >>>>> From: "marcelo bagnulo braun" >>>>> To: ; "mext" ; >>>>> Cc: ; "Ralph Droms" >>>>> Sent: Sunday, June 28, 2009 1:16 PM >>>>> Subject: [netlmm] NEXTEXT2: first draft of the bof description >>>>> >>>>> >>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> This is a first draft of the BOF description for your consideration. >>>>>> It >>>>>> is >>>>>> still very open so, feel free to comment on whether the proposed >>>>>> approach >>>>>> seems appropriate or not. >>>>>> >>>>>> NETEXT2 BOF description >>>>>> ----------------------- >>>>>> >>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility >>>>>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to >>>>>> IP hosts without requiring any protocol enhancements or additional >>>>>> capabilities on the host. >>>>>> Current PMIP6 specification fully defines how to provide mobility >>>>>> support for mobile nodes with a single interface roaming in a PMIP6 >>>>>> domain. The goal of this BOF is gain understanding of how to support >>>>>> nodes with multiple interfaces (of possible different technologies) = in >>>>>> a >>>>>> PMIP6 network. >>>>>> >>>>>> In particular, this BOF assumes the following scenario: >>>>>> We have a single PMIP6 domain that has deployed multiple >>>>>> access technologies and needs to support nodes that have >>>>>> multiple interfaces, possibly of different technologies. >>>>>> >>>>>> In particular, the following capabilities are needed: >>>>>> >>>>>> - Inter-technology handover support. The MN has initiated a >>>>>> communication over one interface and it needs to be able to move >>>>>> the established connection to a different interface of >>>>>> a possibly different technology. The reason for moving >>>>>> the communication to another interface is because of the MNs >>>>>> mobility and attaching via a different interface. Basically >>>>>> the ability to perform handovers that span different access >>>>>> technologies. >>>>>> >>>>>> - Multihoming support. The MN with multiple interfaces of possibly >>>>>> different technologies should be able to use them simultaneously to >>>>>> exchange data and manage the mobility of communications >>>>>> established through the different interfaces. >>>>>> >>>>>> - Flow mobility. A MN with multiple interfaces of possibly >>>>>> different technologies must be able to move a flow from >>>>>> one interface to another. Moreover, the MN should be able >>>>>> to inform the network through which interface it wishes >>>>>> to receive different types of flows. >>>>>> >>>>>> In order to provide the support for these capabilities, different >>>>>> approaches can be envisioned, namely: >>>>>> - L2 only approaches. In this type of approaches, the mechanisms >>>>>> to provide the required capabilities are fully L2 mechanisms and >>>>>> no modification of the IP layer is needed. >>>>>> - L3 only approaches. In this type of approaches, the mechanism to >>>>>> provide to required capabilities are located in the IP layer >>>>>> - Hybrid L2/L3 approaches. In this case, some mechanisms are >>>>>> located in L2 and other mechanisms are located in L3. >>>>>> Now, the different possible approaches vary greatly in their nature >>>>>> and resulting capabilities. To understanding the benefits and >>>>>> suitability of these alternatives, the requirements have to be >>>>>> properly defined and understood. >>>>>> >>>>>> The main goal of the BOF is understanding the need for work in the >>>>>> IETF in this area. In order to do so, during the BOF, we will attemp= t >>>>>> to: >>>>>> >>>>>> 1) Understand the applicable scenarios, and the problem statement >>>>>> related >>>>>> to >>>>>> those >>>>>> 2) Understand the restrictions and requirement imposed to solutions = to >>>>>> address the problem statement and scenarios >>>>>> 3) Get an overview of the proposed solutions >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> netlmm mailing list >>>>>> netlmm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netlmm >>>>>> >>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From marcelo@it.uc3m.es Tue Jun 30 05:39:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34DF53A6E55; Tue, 30 Jun 2009 05:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.259 X-Spam-Level: X-Spam-Status: No, score=-6.259 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] 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 NxZ1mcC2hN3I; Tue, 30 Jun 2009 05:39:23 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 3DEB43A69E7; Tue, 30 Jun 2009 05:39:22 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-138.dynamic.orange.es [85.53.138.110]) by smtp03.uc3m.es (Postfix) with ESMTP id DC48072C69B; Tue, 30 Jun 2009 14:39:27 +0200 (CEST) Message-ID: <4A4A0780.6000508@it.uc3m.es> Date: Tue, 30 Jun 2009 14:39:28 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: George Tsirtsis References: <4A495FBB.9090106@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16734.007 Cc: Basavaraj.Patil@nokia.com, "netlmm@ietf.org" , mext Subject: Re: [MEXT] [netlmm] [netext] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 12:39:25 -0000 George, great summary just one comment below... George Tsirtsis escribió: > With PMIP things are not so clear....it is not even clear we are > talking about the *network layer*... and thus it is not so clear how > "generic" solutions can be. > > right, so one relevant question is how generic we want this to be. For instance, it may be also sufficient to support inter technology handovers for a subset of L2 technologies that can support it at the L2 as you stated. So, one thing that we need to define is whether we are looking for a solution that supports inter technology handover with any two L2 combiantios or are we looking for a solution that supports inter technology handovers for a limited set of technologies? I think this is a key requirements that we need to be explicit about. > The challenge for the BOF is to throw some light on how PMIP can be > compatible with this extended functionality, what type of additional > signalling is needed, and at which layer they intend to implement such > signalling. Let's see. > > while i agree with that, i think a first step that this bof needs to throw some light on is what are the functional requirements for the support of the required features. I think the previous is a good example of one requirement that we need to flesh out. There are many others. Regards, marcelo > George > > On Tue, Jun 30, 2009 at 1:43 AM, Charles E. > Perkins wrote: > >> Hello Basavaraj, >> >> Isn't make-before-break a function performed >> at the link layer? >> >> It certainly isn't PHY, and I wouldn't think it >> qualifies as MAC (i.e., it doesn't control the >> device's access to the medium). >> >> Regards, >> Charlie P. >> >> PS. Which is the proper mailing list for this discussion? >> >> Basavaraj.Patil@nokia.com wrote: >> >>> Hi Frank, >>> >>> Make-before-break is inherently supported in certain technologies such as >>> CDMA/WCDMA (which has soft HO features built in). The same is not possible >>> for example in TDMA (GSM) or OFDMA (802.16e and WiFi). 802.16e does have a >>> contorted mechansim for achieving the same but that's besides the point. >>> So IMO it is a capability of the Phy/Mac. >>> However it is possible to emulate soft-handovers and achieve >>> make-before-break in certain cases. For example it is possible to be >>> simultaneously connected to HSPA and WiFi and accomplish a >>> make-before-break >>> HO. I guess the definition of the term depends on an access tchnology or >>> the >>> combination of access technologies in the context of a use-case. >>> >>> -Raj >>> >>> >>> On 6/29/09 4:36 PM, "ext Frank Xia" wrote: >>> >>> >>> >>>> Hi Raj >>>> >>>> IMHO Make-before-break is not a link-layer technology. >>>> , but a concept (or a strategy). Related to the topic we >>>> are discussing, making target interface ready before moving >>>> traffic to it is kind of make-before-break. >>>> >>>> BR >>>> Frank >>>> >>>> ----- Original Message ----- >>>> From: >>>> To: ; ; ; >>>> ; >>>> Cc: ; >>>> Sent: Monday, June 29, 2009 3:43 PM >>>> Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof >>>> description >>>> >>>> >>>> >>>> Hi Frank, >>>> >>>> Comments inline: >>>> >>>> >>>> On 6/29/09 2:57 PM, "ext Frank Xia" wrote: >>>> >>>> >>>> >>>>> Hi Raj >>>>> >>>>> My main point is make-before-break strategy >>>>> is the best way to solve multi-radio handover. >>>>> >>>>> >>>> The IETF cannot do anything about whether an MN has the ability to >>>> accomplish make-before-break connectivity. It depends on the link-layer >>>> technology, spectrum that they operate in, etc. So this approach is a >>>> non-starter. The IETF solution has to be agnostic to underlying access >>>> technologies. >>>> >>>> >>>> >>>>> Please see my inline response. >>>>> >>>>> BR >>>>> ----- Original Message ----- >>>>> From: >>>>> To: ; ; ; >>>>> ; >>>>> Cc: ; >>>>> Sent: Monday, June 29, 2009 11:50 AM >>>>> Subject: Re: [netlmm] NEXTEXT2: first draft of the bof description >>>>> >>>>> >>>>> >>>>> Frank, >>>>> >>>>> >>>>> On 6/29/09 11:16 AM, "ext Frank Xia" wrote: >>>>> >>>>> >>>>> >>>>>> Hi Guys >>>>>> >>>>>> I have comments on inter-technology handover. >>>>>> >>>>>> IMHO, flow mobility could solve problems >>>>>> which inter-tech handover is try to deal with. >>>>>> >>>>>> >>>>> Flow mobility also includes the ability to move a flow from one mobility >>>>> session to another. Multiple mobility sessions could be established via >>>>> a >>>>> single interface in which case flow mobility would be achieved within >>>>> the >>>>> scope of a single interface. Hence flow mobility and inter-technology >>>>> handovers are separate features. >>>>> Frank=>IMHO, inter-technology is trying to move all the traffic on >>>>> one interface to another interface. >>>>> >>>>> >>>> Right. I guess you answered the question about the difference between >>>> flow >>>> mobility and inter-technology handovers. You could extrapolate and say >>>> that >>>> inter-technology HO is the case where you move all flows from one >>>> interface >>>> to another and hence a variant of flow mobility. While that is true, you >>>> should also recognize that the granularity of flow mobility is finer and >>>> does not have to necessarily be a relocation of a flow between physical >>>> interfaces. >>>> >>>> >>>>>> I assume that two heterogeneous interfaces are >>>>>> all active during the handover. It is easy to move >>>>>> a flow(or all flows) from an interface to another. >>>>>> >>>>>> >>>>> Possibly.. But the point is to identify what extensions (possibly to the >>>>> MN) >>>>> are needed in order to achieve handovers across interfaces. >>>>> Frank=>If we see inter-tech handover as a subset of flow mobility, >>>>> there is one problem left, that is flow mobility. >>>>> >>>>> >>>> See above. Flow mobility is a feature that can work across multiple >>>> mobility >>>> sessions within the scope of a single interface as well. >>>> >>>> >>>> >>>>>> This is probably the reason why there is no >>>>>> inter-tech handover solution standerdized >>>>>> for client MIP. >>>>>> >>>>>> >>>>> Client MIP inherently supports handovers across multiple interfaces. >>>>> Performance improvements to the handovers are accomplished using >>>>> solutions >>>>> such as FMIP. >>>>> Frank=>Maybe, I am missing something. However FMIP is not applicable >>>>> to PAR/NAR collocated scenario. For example, a mobile node with two >>>>> interface connects to the same access router (ASN-GW for WiMAX, >>>>> PDN-GW for LTE). Does FMIP work when mobile node handover from >>>>> one technology to another? >>>>> >>>>> >>>> Not sure I understand the question. In your example above, I believe the >>>> MN >>>> would connect to the ASN-GW via the WiMAX interface and to an S-GW via >>>> the >>>> LTE interface. The P-GW (LMA) may be the same. If the question is, can >>>> you >>>> use FMIP to optimize handovers in such a scenario... Yes. Not FMIP, but >>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't think we are looking at >>>> optimizing >>>> handovers in this discussion. >>>> As per the current PMIP6 specification wherein no changes to the host are >>>> required, it is not possible to do an inter-technology handover. This is >>>> a >>>> limitation which implies that PMIP6 provides host mobility to an MN >>>> within >>>> the scope of a single access technology. Host based mobile IP does not >>>> have >>>> this problem. >>>> >>>> -Raj >>>> >>>> >>>> >>>>> -Raj >>>>> >>>>> >>>>> >>>>>> BR >>>>>> Frank >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "marcelo bagnulo braun" >>>>>> To: ; "mext" ; >>>>>> Cc: ; "Ralph Droms" >>>>>> Sent: Sunday, June 28, 2009 1:16 PM >>>>>> Subject: [netlmm] NEXTEXT2: first draft of the bof description >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> This is a first draft of the BOF description for your consideration. >>>>>>> It >>>>>>> is >>>>>>> still very open so, feel free to comment on whether the proposed >>>>>>> approach >>>>>>> seems appropriate or not. >>>>>>> >>>>>>> NETEXT2 BOF description >>>>>>> ----------------------- >>>>>>> >>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility >>>>>>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to >>>>>>> IP hosts without requiring any protocol enhancements or additional >>>>>>> capabilities on the host. >>>>>>> Current PMIP6 specification fully defines how to provide mobility >>>>>>> support for mobile nodes with a single interface roaming in a PMIP6 >>>>>>> domain. The goal of this BOF is gain understanding of how to support >>>>>>> nodes with multiple interfaces (of possible different technologies) in >>>>>>> a >>>>>>> PMIP6 network. >>>>>>> >>>>>>> In particular, this BOF assumes the following scenario: >>>>>>> We have a single PMIP6 domain that has deployed multiple >>>>>>> access technologies and needs to support nodes that have >>>>>>> multiple interfaces, possibly of different technologies. >>>>>>> >>>>>>> In particular, the following capabilities are needed: >>>>>>> >>>>>>> - Inter-technology handover support. The MN has initiated a >>>>>>> communication over one interface and it needs to be able to move >>>>>>> the established connection to a different interface of >>>>>>> a possibly different technology. The reason for moving >>>>>>> the communication to another interface is because of the MNs >>>>>>> mobility and attaching via a different interface. Basically >>>>>>> the ability to perform handovers that span different access >>>>>>> technologies. >>>>>>> >>>>>>> - Multihoming support. The MN with multiple interfaces of possibly >>>>>>> different technologies should be able to use them simultaneously to >>>>>>> exchange data and manage the mobility of communications >>>>>>> established through the different interfaces. >>>>>>> >>>>>>> - Flow mobility. A MN with multiple interfaces of possibly >>>>>>> different technologies must be able to move a flow from >>>>>>> one interface to another. Moreover, the MN should be able >>>>>>> to inform the network through which interface it wishes >>>>>>> to receive different types of flows. >>>>>>> >>>>>>> In order to provide the support for these capabilities, different >>>>>>> approaches can be envisioned, namely: >>>>>>> - L2 only approaches. In this type of approaches, the mechanisms >>>>>>> to provide the required capabilities are fully L2 mechanisms and >>>>>>> no modification of the IP layer is needed. >>>>>>> - L3 only approaches. In this type of approaches, the mechanism to >>>>>>> provide to required capabilities are located in the IP layer >>>>>>> - Hybrid L2/L3 approaches. In this case, some mechanisms are >>>>>>> located in L2 and other mechanisms are located in L3. >>>>>>> Now, the different possible approaches vary greatly in their nature >>>>>>> and resulting capabilities. To understanding the benefits and >>>>>>> suitability of these alternatives, the requirements have to be >>>>>>> properly defined and understood. >>>>>>> >>>>>>> The main goal of the BOF is understanding the need for work in the >>>>>>> IETF in this area. In order to do so, during the BOF, we will attempt >>>>>>> to: >>>>>>> >>>>>>> 1) Understand the applicable scenarios, and the problem statement >>>>>>> related >>>>>>> to >>>>>>> those >>>>>>> 2) Understand the restrictions and requirement imposed to solutions to >>>>>>> address the problem statement and scenarios >>>>>>> 3) Get an overview of the proposed solutions >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> netlmm mailing list >>>>>>> netlmm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netlmm >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> netext mailing list >>>>> netext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netext >>>>> >>>>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm > From hesham@elevatemobile.com Tue Jun 30 06:19:30 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E01EA28C3E2; Tue, 30 Jun 2009 06:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] 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 63FTgSPMA6+3; Tue, 30 Jun 2009 06:19:29 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id A479428C3D3; Tue, 30 Jun 2009 06:19:27 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MLdEp-0000jo-9b; Tue, 30 Jun 2009 23:19:08 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 30 Jun 2009 23:19:00 +1000 From: Hesham Soliman To: marcelo bagnulo braun , George Tsirtsis Message-ID: Thread-Topic: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description Thread-Index: Acn5hVR54aGANsUyb0+KvghblE9/wA== In-Reply-To: <4A4A0780.6000508@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext , "netlmm@ietf.org" , Basavaraj.Patil@nokia.com Subject: Re: [MEXT] [netlmm] [netext] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 13:19:31 -0000 A quick comment.=20 I don't see any reason for an IETF WG to look for a solution that works for a limited set of technologies and try to solve that on layer 2. This is clearly not our job. Similarly, there is little gain in solving this for a limited set of technologies on L3 given that we already have a layer 2 agnostic solution. Why would we want to develop another one for a limited set of link layers? Hesham On 30/06/09 10:39 PM, "marcelo bagnulo braun" wrote: > George, great summary just one comment below... George Tsirtsis > escribi=F3: > With PMIP things are not so clear....it is not even clear we are > > talking about the *network layer*... and thus it is not so clear how > > "generic" solutions can be. > > right, so one relevant question is how > generic we want this to be. For instance, it may be also sufficient to support > inter technology handovers for a subset of L2 technologies that can support > it at the L2 as you stated. So, one thing that we need to define is whether > we are looking for a solution that supports inter technology handover with > any two L2 combiantios or are we looking for a solution that supports inter > technology handovers for a limited set of technologies? I think this is a key > requirements that we need to be explicit about. > The challenge for the BOF > is to throw some light on how PMIP can be > compatible with this extended > functionality, what type of additional > signalling is needed, and at which > layer they intend to implement such > signalling. Let's see. > > while i > agree with that, i think a first step that this bof needs to throw some light > on is what are the functional requirements for the support of the required > features. I think the previous is a good example of one requirement that we > need to flesh out. There are many others. Regards, marcelo > George > > On > Tue, Jun 30, 2009 at 1:43 AM, Charles E. > > Perkins wrote: > >> Hello Basavaraj, >> >> > Isn't make-before-break a function performed >> at the link layer? >> >> It > certainly isn't PHY, and I wouldn't think it >> qualifies as MAC (i.e., it > doesn't control the >> device's access to the medium). >> >> Regards, >> > Charlie P. >> >> PS. Which is the proper mailing list for this > discussion? >> >> Basavaraj.Patil@nokia.com wrote: >> >>> Hi > Frank, >>> >>> Make-before-break is inherently supported in certain > technologies such as >>> CDMA/WCDMA (which has soft HO features built in). The > same is not possible >>> for example in TDMA (GSM) or OFDMA (802.16e and > WiFi). 802.16e does have a >>> contorted mechansim for achieving the same but > that's besides the point. >>> So IMO it is a capability of the Phy/Mac. >>> > However it is possible to emulate soft-handovers and achieve >>> > make-before-break in certain cases. For example it is possible to be >>> > simultaneously connected to HSPA and WiFi and accomplish a >>> > make-before-break >>> HO. I guess the definition of the term depends on an > access tchnology or >>> the >>> combination of access technologies in the > context of a use-case. >>> >>> -Raj >>> >>> >>> On 6/29/09 4:36 PM, "ext Frank > Xia" wrote: >>> >>> >>> >>>> Hi Raj >>>> >>>> > IMHO Make-before-break is not a link-layer technology. >>>> , but a concept > (or a strategy). Related to the topic we >>>> are discussing, making target > interface ready before moving >>>> traffic to it is kind of > make-before-break. >>>> >>>> BR >>>> Frank >>>> >>>> ----- Original Message > ----- >>>> From: >>>> To: > ; ; ; >>>> > ; >>>> Cc: ; > >>>> Sent: Monday, June 29, 2009 3:43 PM >>>> Subject: Re: > [netext] [netlmm] NEXTEXT2: first draft of the bof >>>> > description >>>> >>>> >>>> >>>> Hi Frank, >>>> >>>> Comments > inline: >>>> >>>> >>>> On 6/29/09 2:57 PM, "ext Frank Xia" > wrote: >>>> >>>> >>>> >>>>> Hi > Raj >>>>> >>>>> My main point is make-before-break strategy >>>>> is the best > way to solve multi-radio handover. >>>>> >>>>> >>>> The IETF cannot > do anything about whether an MN has the ability to >>>> accomplish > make-before-break connectivity. It depends on the link-layer >>>> technology, > spectrum that they operate in, etc. So this approach is a >>>> non-starter. > The IETF solution has to be agnostic to underlying access >>>> > technologies. >>>> >>>> >>>> >>>>> Please see my inline > response. >>>>> >>>>> BR >>>>> ----- Original Message ----- >>>>> From: > >>>>> To: ; > ; ; >>>>> ; > >>>>> Cc: ; > >>>>> Sent: Monday, June 29, 2009 11:50 AM >>>>> Subject: > Re: [netlmm] NEXTEXT2: first draft of the bof > description >>>>> >>>>> >>>>> >>>>> Frank, >>>>> >>>>> >>>>> On 6/29/09 11:16 > AM, "ext Frank Xia" wrote: >>>>> >>>>> >>>>> > >>>>>> Hi Guys >>>>>> >>>>>> I have comments on inter-technology > handover. >>>>>> >>>>>> IMHO, flow mobility could solve problems >>>>>> which > inter-tech handover is try to deal with. >>>>>> >>>>>> >>>>> Flow > mobility also includes the ability to move a flow from one mobility >>>>> > session to another. Multiple mobility sessions could be established via >>>>> > a >>>>> single interface in which case flow mobility would be achieved > within >>>>> the >>>>> scope of a single interface. Hence flow mobility and > inter-technology >>>>> handovers are separate features. >>>>> Frank=3D>IMHO, > inter-technology is trying to move all the traffic on >>>>> one interface to > another interface. >>>>> >>>>> >>>> Right. I guess you answered the > question about the difference between >>>> flow >>>> mobility and > inter-technology handovers. You could extrapolate and say >>>> that >>>> > inter-technology HO is the case where you move all flows from one >>>> > interface >>>> to another and hence a variant of flow mobility. While that is > true, you >>>> should also recognize that the granularity of flow mobility is > finer and >>>> does not have to necessarily be a relocation of a flow between > physical >>>> interfaces. >>>> >>>> >>>>>> I assume that two > heterogeneous interfaces are >>>>>> all active during the handover. It is > easy to move >>>>>> a flow(or all flows) from an interface to > another. >>>>>> >>>>>> >>>>> Possibly.. But the point is to > identify what extensions (possibly to the >>>>> MN) >>>>> are needed in order > to achieve handovers across interfaces. >>>>> Frank=3D>If we see inter-tech > handover as a subset of flow mobility, >>>>> there is one problem left, that > is flow mobility. >>>>> >>>>> >>>> See above. Flow mobility is a > feature that can work across multiple >>>> mobility >>>> sessions within the > scope of a single interface as well. >>>> >>>> >>>> >>>>>> This is > probably the reason why there is no >>>>>> inter-tech handover solution > standerdized >>>>>> for client MIP. >>>>>> >>>>>> >>>>> Client > MIP inherently supports handovers across multiple interfaces. >>>>> > Performance improvements to the handovers are accomplished using >>>>> > solutions >>>>> such as FMIP. >>>>> Frank=3D>Maybe, I am missing something. > However FMIP is not applicable >>>>> to PAR/NAR collocated scenario. For > example, a mobile node with two >>>>> interface connects to the same access > router (ASN-GW for WiMAX, >>>>> PDN-GW for LTE). Does FMIP work when mobile > node handover from >>>>> one technology to another? >>>>> >>>>> > >>>> Not sure I understand the question. In your example above, I believe > the >>>> MN >>>> would connect to the ASN-GW via the WiMAX interface and to an > S-GW via >>>> the >>>> LTE interface. The P-GW (LMA) may be the same. If the > question is, can >>>> you >>>> use FMIP to optimize handovers in such a > scenario... Yes. Not FMIP, but >>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't > think we are looking at >>>> optimizing >>>> handovers in this > discussion. >>>> As per the current PMIP6 specification wherein no changes to > the host are >>>> required, it is not possible to do an inter-technology > handover. This is >>>> a >>>> limitation which implies that PMIP6 provides > host mobility to an MN >>>> within >>>> the scope of a single access > technology. Host based mobile IP does not >>>> have >>>> this > problem. >>>> >>>> -Raj >>>> >>>> >>>> >>>>> -Raj >>>>> >>>>> >>>>> > >>>>>> BR >>>>>> Frank >>>>>> >>>>>> ----- Original Message ----- >>>>>> > From: "marcelo bagnulo braun" >>>>>> To: > ; "mext" ; >>>>>> Cc: > ; "Ralph Droms" >>>>>> Sent: > Sunday, June 28, 2009 1:16 PM >>>>>> Subject: [netlmm] NEXTEXT2: first draft > of the bof description >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> > Hi, >>>>>>> >>>>>>> This is a first draft of the BOF description for your > consideration. >>>>>>> It >>>>>>> is >>>>>>> still very open so, feel free to > comment on whether the proposed >>>>>>> approach >>>>>>> seems appropriate or > not. >>>>>>> >>>>>>> NETEXT2 BOF description >>>>>>> > ----------------------- >>>>>>> >>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is > a network based mobility >>>>>>> protocol built on Mobile IPv6 [RFC3775]. > PMIP6 provides mobility to >>>>>>> IP hosts without requiring any protocol > enhancements or additional >>>>>>> capabilities on the host. >>>>>>> Current > PMIP6 specification fully defines how to provide mobility >>>>>>> support for > mobile nodes with a single interface roaming in a PMIP6 >>>>>>> domain. The > goal of this BOF is gain understanding of how to support >>>>>>> nodes with > multiple interfaces (of possible different technologies) in >>>>>>> a >>>>>>> > PMIP6 network. >>>>>>> >>>>>>> In particular, this BOF assumes the following > scenario: >>>>>>> We have a single PMIP6 domain that has deployed > multiple >>>>>>> access technologies and needs to support nodes that > have >>>>>>> multiple interfaces, possibly of different > technologies. >>>>>>> >>>>>>> In particular, the following capabilities are > needed: >>>>>>> >>>>>>> - Inter-technology handover support. The MN has > initiated a >>>>>>> communication over one interface and it needs to be able > to move >>>>>>> the established connection to a different interface of >>>>>>> > a possibly different technology. The reason for moving >>>>>>> the > communication to another interface is because of the MNs >>>>>>> mobility and > attaching via a different interface. Basically >>>>>>> the ability to perform > handovers that span different access >>>>>>> technologies. >>>>>>> >>>>>>> - > Multihoming support. The MN with multiple interfaces of possibly >>>>>>> > different technologies should be able to use them simultaneously to >>>>>>> > exchange data and manage the mobility of communications >>>>>>> established > through the different interfaces. >>>>>>> >>>>>>> - Flow mobility. A MN with > multiple interfaces of possibly >>>>>>> different technologies must be able to > move a flow from >>>>>>> one interface to another. Moreover, the MN should be > able >>>>>>> to inform the network through which interface it wishes >>>>>>> > to receive different types of flows. >>>>>>> >>>>>>> In order to provide the > support for these capabilities, different >>>>>>> approaches can be > envisioned, namely: >>>>>>> - L2 only approaches. In this type of approaches, > the mechanisms >>>>>>> to provide the required capabilities are fully L2 > mechanisms and >>>>>>> no modification of the IP layer is needed. >>>>>>> - L3 > only approaches. In this type of approaches, the mechanism to >>>>>>> provide > to required capabilities are located in the IP layer >>>>>>> - Hybrid L2/L3 > approaches. In this case, some mechanisms are >>>>>>> located in L2 and other > mechanisms are located in L3. >>>>>>> Now, the different possible approaches > vary greatly in their nature >>>>>>> and resulting capabilities. To > understanding the benefits and >>>>>>> suitability of these alternatives, the > requirements have to be >>>>>>> properly defined and > understood. >>>>>>> >>>>>>> The main goal of the BOF is understanding the need > for work in the >>>>>>> IETF in this area. In order to do so, during the BOF, > we will attempt >>>>>>> to: >>>>>>> >>>>>>> 1) Understand the applicable > scenarios, and the problem statement >>>>>>> related >>>>>>> to >>>>>>> > those >>>>>>> 2) Understand the restrictions and requirement imposed to > solutions to >>>>>>> address the problem statement and scenarios >>>>>>> 3) > Get an overview of the proposed solutions >>>>>>> >>>>>>> >>>>>>> > _______________________________________________ >>>>>>> netlmm mailing > list >>>>>>> netlmm@ietf.org >>>>>>> > https://www.ietf.org/mailman/listinfo/netlmm >>>>>>> >>>>>>> > >>>>> _______________________________________________ >>>>> netext mailing > list >>>>> netext@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/netext >>>>> >>>>> >>> > _______________________________________________ >>> MEXT mailing list >>> > MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> >>> > >> _______________________________________________ >> MEXT mailing list >> > MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > _______________________________________________ > netlmm mailing list > > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ netlmm mailing > list netlmm@ietf.org https://www.ietf.org/mailman/listinfo/netlmm From marcelo@it.uc3m.es Tue Jun 30 06:30:37 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03AA3A6E67; Tue, 30 Jun 2009 06:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.252 X-Spam-Level: X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] 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 eEnKIVn6OA3M; Tue, 30 Jun 2009 06:30:35 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 7D3273A6E6A; Tue, 30 Jun 2009 06:30:34 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-138.dynamic.orange.es [85.53.138.110]) by smtp02.uc3m.es (Postfix) with ESMTP id 89D536C1C1A; Tue, 30 Jun 2009 15:29:14 +0200 (CEST) Message-ID: <4A4A132A.3010307@it.uc3m.es> Date: Tue, 30 Jun 2009 15:29:14 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16734.007 Cc: mext , "netlmm@ietf.org" , Basavaraj.Patil@nokia.com Subject: Re: [MEXT] [netlmm] [netext] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 13:30:37 -0000 Hesham, I am not commenting on whether we should do this in the IETF or not, I am just stating that we first need to understand what are the needs of the people that are running these networks. So, among the things i would like to understnad is that when they say they need to support intertechnology handovers, whether they need to do it for any L2 combination, or just a limited/defined set of technologies that have some special characteristics? I think it is relevant to understnad this point in order to understnad the problem better. Regards, marcelo Hesham Soliman escribió: > A quick comment. > I don't see any reason for an IETF WG to look for a solution that works for > a limited set of technologies and try to solve that on layer 2. This is > clearly not our job. Similarly, there is little gain in solving this for a > limited set of technologies on L3 given that we already have a layer 2 > agnostic solution. Why would we want to develop another one for a limited > set of link layers? > > Hesham > > > On 30/06/09 10:39 PM, "marcelo bagnulo braun" wrote: > > >> George, >> > > > great summary > > just one comment below... > > > George Tsirtsis > >> escribió: >> With PMIP things are not so clear....it is not even clear we are >> >> talking about the *network layer*... and thus it is not so clear how >> >> "generic" solutions can be. >> >> >> > right, so one relevant question is how > >> generic we want this to be. >> > For instance, it may be also sufficient to support > >> inter technology >> > handovers for a subset of L2 technologies that can support > >> it at the L2 >> > as you stated. > So, one thing that we need to define is whether > >> we are looking for a >> > solution that supports inter technology handover with > >> any two L2 >> > combiantios or are we looking for a solution that supports inter > > technology handovers for a limited set of technologies? > I think this is a key > >> requirements that we need to be explicit about. >> > > > >> The challenge for the BOF >> is to throw some light on how PMIP can be >> compatible with this extended >> functionality, what type of additional >> signalling is needed, and at which >> layer they intend to implement such >> signalling. Let's see. >> >> >> > > while i > >> agree with that, i think a first step that this bof needs to >> > throw some light > >> on is what are the functional requirements for the >> > support of the required > >> features. I think the previous is a good example >> > of one requirement that we > >> need to flesh out. There are many others. >> > > Regards, marcelo > > > >> George >> >> On >> Tue, Jun 30, 2009 at 1:43 AM, Charles E. >> >> Perkins wrote: >> >> >>> Hello Basavaraj, >>> >>> >>> >> Isn't make-before-break a function performed >> >>> at the link layer? >>> >>> It >>> >> certainly isn't PHY, and I wouldn't think it >> >>> qualifies as MAC (i.e., it >>> >> doesn't control the >> >>> device's access to the medium). >>> >>> Regards, >>> >>> >> Charlie P. >> >>> PS. Which is the proper mailing list for this >>> >> discussion? >> >>> Basavaraj.Patil@nokia.com wrote: >>> >>> >>>> Hi >>>> >> Frank, >> >>>> Make-before-break is inherently supported in certain >>>> >> technologies such as >> >>>> CDMA/WCDMA (which has soft HO features built in). The >>>> >> same is not possible >> >>>> for example in TDMA (GSM) or OFDMA (802.16e and >>>> >> WiFi). 802.16e does have a >> >>>> contorted mechansim for achieving the same but >>>> >> that's besides the point. >> >>>> So IMO it is a capability of the Phy/Mac. >>>> >>>> >> However it is possible to emulate soft-handovers and achieve >> >> make-before-break in certain cases. For example it is possible to be >> >> simultaneously connected to HSPA and WiFi and accomplish a >> >> make-before-break >> >>>> HO. I guess the definition of the term depends on an >>>> >> access tchnology or >> >>>> the >>>> combination of access technologies in the >>>> >> context of a use-case. >> >>>> -Raj >>>> >>>> >>>> On 6/29/09 4:36 PM, "ext Frank >>>> >> Xia" wrote: >> >>>> >>>> >>>>> Hi Raj >>>>> >>>>> >>>>> >> IMHO Make-before-break is not a link-layer technology. >> >>>>> , but a concept >>>>> >> (or a strategy). Related to the topic we >> >>>>> are discussing, making target >>>>> >> interface ready before moving >> >>>>> traffic to it is kind of >>>>> >> make-before-break. >> >>>>> BR >>>>> Frank >>>>> >>>>> ----- Original Message >>>>> >> ----- >> >>>>> From: >>>>> To: >>>>> >> ; ; ; >> >> ; >> >>>>> Cc: ; >>>>> >> >> >>>>> Sent: Monday, June 29, 2009 3:43 PM >>>>> Subject: Re: >>>>> >> [netext] [netlmm] NEXTEXT2: first draft of the bof >> >> description >> >>>>> >>>>> Hi Frank, >>>>> >>>>> Comments >>>>> >> inline: >> >>>>> On 6/29/09 2:57 PM, "ext Frank Xia" >>>>> >> wrote: >> >>>>> >>>>> >>>>>> Hi >>>>>> >> Raj >> >>>>>> My main point is make-before-break strategy >>>>>> is the best >>>>>> >> way to solve multi-radio handover. >> >>>>>> >>>>>> >>>>> The IETF cannot >>>>> >> do anything about whether an MN has the ability to >> >>>>> accomplish >>>>> >> make-before-break connectivity. It depends on the link-layer >> >>>>> technology, >>>>> >> spectrum that they operate in, etc. So this approach is a >> >>>>> non-starter. >>>>> >> The IETF solution has to be agnostic to underlying access >> >> technologies. >> >>>>> >>>>> >>>>>> Please see my inline >>>>>> >> response. >> >>>>>> BR >>>>>> ----- Original Message ----- >>>>>> From: >>>>>> >> >> >>>>>> To: ; >>>>>> >> ; ; >> >>>>>> ; >>>>>> >> >> >>>>>> Cc: ; >>>>>> >> >> >>>>>> Sent: Monday, June 29, 2009 11:50 AM >>>>>> Subject: >>>>>> >> Re: [netlmm] NEXTEXT2: first draft of the bof >> description >> >>>>>> >>>>>> Frank, >>>>>> >>>>>> >>>>>> On 6/29/09 11:16 >>>>>> >> AM, "ext Frank Xia" wrote: >> >>>>>> >>>>>> >>>>>>> Hi Guys >>>>>>> >>>>>>> I have comments on inter-technology >>>>>>> >> handover. >> >>>>>>> IMHO, flow mobility could solve problems >>>>>>> which >>>>>>> >> inter-tech handover is try to deal with. >> >>>>>>> >>>>>>> >>>>>> Flow >>>>>> >> mobility also includes the ability to move a flow from one mobility >> >> session to another. Multiple mobility sessions could be established via >> >> a >> >>>>>> single interface in which case flow mobility would be achieved >>>>>> >> within >> >>>>>> the >>>>>> scope of a single interface. Hence flow mobility and >>>>>> >> inter-technology >> >>>>>> handovers are separate features. >>>>>> Frank=>IMHO, >>>>>> >> inter-technology is trying to move all the traffic on >> >>>>>> one interface to >>>>>> >> another interface. >> >>>>>> >>>>>> >>>>> Right. I guess you answered the >>>>> >> question about the difference between >> >>>>> flow >>>>> mobility and >>>>> >> inter-technology handovers. You could extrapolate and say >> >>>>> that >>>>> >>>>> >> inter-technology HO is the case where you move all flows from one >> >> interface >> >>>>> to another and hence a variant of flow mobility. While that is >>>>> >> true, you >> >>>>> should also recognize that the granularity of flow mobility is >>>>> >> finer and >> >>>>> does not have to necessarily be a relocation of a flow between >>>>> >> physical >> >>>>> interfaces. >>>>> >>>>> >>>>> >>>>>>> I assume that two >>>>>>> >> heterogeneous interfaces are >> >>>>>>> all active during the handover. It is >>>>>>> >> easy to move >> >>>>>>> a flow(or all flows) from an interface to >>>>>>> >> another. >> >>>>>>> >>>>>>> >>>>>> Possibly.. But the point is to >>>>>> >> identify what extensions (possibly to the >> >>>>>> MN) >>>>>> are needed in order >>>>>> >> to achieve handovers across interfaces. >> >>>>>> Frank=>If we see inter-tech >>>>>> >> handover as a subset of flow mobility, >> >>>>>> there is one problem left, that >>>>>> >> is flow mobility. >> >>>>>> >>>>>> >>>>> See above. Flow mobility is a >>>>> >> feature that can work across multiple >> >>>>> mobility >>>>> sessions within the >>>>> >> scope of a single interface as well. >> >>>>> >>>>> >>>>>>> This is >>>>>>> >> probably the reason why there is no >> >>>>>>> inter-tech handover solution >>>>>>> >> standerdized >> >>>>>>> for client MIP. >>>>>>> >>>>>>> >>>>>>> >>>>>> Client >>>>>> >> MIP inherently supports handovers across multiple interfaces. >> >> Performance improvements to the handovers are accomplished using >> >> solutions >> >>>>>> such as FMIP. >>>>>> Frank=>Maybe, I am missing something. >>>>>> >> However FMIP is not applicable >> >>>>>> to PAR/NAR collocated scenario. For >>>>>> >> example, a mobile node with two >> >>>>>> interface connects to the same access >>>>>> >> router (ASN-GW for WiMAX, >> >>>>>> PDN-GW for LTE). Does FMIP work when mobile >>>>>> >> node handover from >> >>>>>> one technology to another? >>>>>> >>>>>> >>>>>> >>>>> Not sure I understand the question. In your example above, I believe >>>>> >> the >> >>>>> MN >>>>> would connect to the ASN-GW via the WiMAX interface and to an >>>>> >> S-GW via >> >>>>> the >>>>> LTE interface. The P-GW (LMA) may be the same. If the >>>>> >> question is, can >> >>>>> you >>>>> use FMIP to optimize handovers in such a >>>>> >> scenario... Yes. Not FMIP, but >> >>>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't >>>>> >> think we are looking at >> >>>>> optimizing >>>>> handovers in this >>>>> >> discussion. >> >>>>> As per the current PMIP6 specification wherein no changes to >>>>> >> the host are >> >>>>> required, it is not possible to do an inter-technology >>>>> >> handover. This is >> >>>>> a >>>>> limitation which implies that PMIP6 provides >>>>> >> host mobility to an MN >> >>>>> within >>>>> the scope of a single access >>>>> >> technology. Host based mobile IP does not >> >>>>> have >>>>> this >>>>> >> problem. >> >>>>> -Raj >>>>> >>>>> >>>>> >>>>> >>>>>> -Raj >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> BR >>>>>>> Frank >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> >>>>>>> >> From: "marcelo bagnulo braun" >> >>>>>>> To: >>>>>>> >> ; "mext" ; >> >>>>>>> Cc: >>>>>>> >> ; "Ralph Droms" >> >>>>>>> Sent: >>>>>>> >> Sunday, June 28, 2009 1:16 PM >> >>>>>>> Subject: [netlmm] NEXTEXT2: first draft >>>>>>> >> of the bof description >> >>>>>>> >>>>>>> >>>>>>> >> Hi, >> >>>>>>>> This is a first draft of the BOF description for your >>>>>>>> >> consideration. >> >>>>>>>> It >>>>>>>> is >>>>>>>> still very open so, feel free to >>>>>>>> >> comment on whether the proposed >> >>>>>>>> approach >>>>>>>> seems appropriate or >>>>>>>> >> not. >> >>>>>>>> NETEXT2 BOF description >>>>>>>> >>>>>>>> >> ----------------------- >> >>>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is >>>>>>>> >> a network based mobility >> >>>>>>>> protocol built on Mobile IPv6 [RFC3775]. >>>>>>>> >> PMIP6 provides mobility to >> >>>>>>>> IP hosts without requiring any protocol >>>>>>>> >> enhancements or additional >> >>>>>>>> capabilities on the host. >>>>>>>> Current >>>>>>>> >> PMIP6 specification fully defines how to provide mobility >> >>>>>>>> support for >>>>>>>> >> mobile nodes with a single interface roaming in a PMIP6 >> >>>>>>>> domain. The >>>>>>>> >> goal of this BOF is gain understanding of how to support >> >>>>>>>> nodes with >>>>>>>> >> multiple interfaces (of possible different technologies) in >> >>>>>>>> a >>>>>>>> >>>>>>>> >> PMIP6 network. >> >>>>>>>> In particular, this BOF assumes the following >>>>>>>> >> scenario: >> >>>>>>>> We have a single PMIP6 domain that has deployed >>>>>>>> >> multiple >> >>>>>>>> access technologies and needs to support nodes that >>>>>>>> >> have >> >>>>>>>> multiple interfaces, possibly of different >>>>>>>> >> technologies. >> >>>>>>>> In particular, the following capabilities are >>>>>>>> >> needed: >> >>>>>>>> - Inter-technology handover support. The MN has >>>>>>>> >> initiated a >> >>>>>>>> communication over one interface and it needs to be able >>>>>>>> >> to move >> >>>>>>>> the established connection to a different interface of >>>>>>>> >>>>>>>> >> a possibly different technology. The reason for moving >> >>>>>>>> the >>>>>>>> >> communication to another interface is because of the MNs >> >>>>>>>> mobility and >>>>>>>> >> attaching via a different interface. Basically >> >>>>>>>> the ability to perform >>>>>>>> >> handovers that span different access >> >>>>>>>> technologies. >>>>>>>> >>>>>>>> - >>>>>>>> >> Multihoming support. The MN with multiple interfaces of possibly >> >> different technologies should be able to use them simultaneously to >> >> exchange data and manage the mobility of communications >> >>>>>>>> established >>>>>>>> >> through the different interfaces. >> >>>>>>>> - Flow mobility. A MN with >>>>>>>> >> multiple interfaces of possibly >> >>>>>>>> different technologies must be able to >>>>>>>> >> move a flow from >> >>>>>>>> one interface to another. Moreover, the MN should be >>>>>>>> >> able >> >>>>>>>> to inform the network through which interface it wishes >>>>>>>> >>>>>>>> >> to receive different types of flows. >> >>>>>>>> In order to provide the >>>>>>>> >> support for these capabilities, different >> >>>>>>>> approaches can be >>>>>>>> >> envisioned, namely: >> >>>>>>>> - L2 only approaches. In this type of approaches, >>>>>>>> >> the mechanisms >> >>>>>>>> to provide the required capabilities are fully L2 >>>>>>>> >> mechanisms and >> >>>>>>>> no modification of the IP layer is needed. >>>>>>>> - L3 >>>>>>>> >> only approaches. In this type of approaches, the mechanism to >> >>>>>>>> provide >>>>>>>> >> to required capabilities are located in the IP layer >> >>>>>>>> - Hybrid L2/L3 >>>>>>>> >> approaches. In this case, some mechanisms are >> >>>>>>>> located in L2 and other >>>>>>>> >> mechanisms are located in L3. >> >>>>>>>> Now, the different possible approaches >>>>>>>> >> vary greatly in their nature >> >>>>>>>> and resulting capabilities. To >>>>>>>> >> understanding the benefits and >> >>>>>>>> suitability of these alternatives, the >>>>>>>> >> requirements have to be >> >>>>>>>> properly defined and >>>>>>>> >> understood. >> >>>>>>>> The main goal of the BOF is understanding the need >>>>>>>> >> for work in the >> >>>>>>>> IETF in this area. In order to do so, during the BOF, >>>>>>>> >> we will attempt >> >>>>>>>> to: >>>>>>>> >>>>>>>> 1) Understand the applicable >>>>>>>> >> scenarios, and the problem statement >> >>>>>>>> related >>>>>>>> to >>>>>>>> >>>>>>>> >> those >> >>>>>>>> 2) Understand the restrictions and requirement imposed to >>>>>>>> >> solutions to >> >>>>>>>> address the problem statement and scenarios >>>>>>>> 3) >>>>>>>> >> Get an overview of the proposed solutions >> >>>>>>>> >>>>>>>> >> _______________________________________________ >> >>>>>>>> netlmm mailing >>>>>>>> >> list >> >>>>>>>> netlmm@ietf.org >>>>>>>> >>>>>>>> >> https://www.ietf.org/mailman/listinfo/netlmm >> >>>>>>>> >>>>>> _______________________________________________ >>>>>> netext mailing >>>>>> >> list >> >>>>>> netext@ietf.org >>>>>> >>>>>> >> https://www.ietf.org/mailman/listinfo/netext >> >>>>>> >>>>>> >> _______________________________________________ >> >>>> MEXT mailing list >>>> >>>> >> MEXT@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> MEXT mailing list >>> >>> >> MEXT@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> >> _______________________________________________ >> netlmm mailing list >> >> netlmm@ietf.org >> https://www.ietf.org/mailman/listinfo/netlmm >> >> >> > > _______________________________________________ > netlmm mailing > >> list >> > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm > > > > > From hesham@elevatemobile.com Tue Jun 30 06:50:09 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E52F3A67CF; Tue, 30 Jun 2009 06:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] 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 NNv68OI-zAjj; Tue, 30 Jun 2009 06:50:07 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 4063A3A6BE4; Tue, 30 Jun 2009 06:50:06 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MLdhW-0001nn-2n; Tue, 30 Jun 2009 23:48:49 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 30 Jun 2009 23:48:40 +1000 From: Hesham Soliman To: marcelo bagnulo braun Message-ID: Thread-Topic: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description Thread-Index: Acn5iXlwnAOxL7OgU0eyLJZ4+zf3Jw== In-Reply-To: <4A4A132A.3010307@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext , "netlmm@ietf.org" , Basavaraj.Patil@nokia.com Subject: Re: [MEXT] [netlmm] [netext] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 13:50:09 -0000 > I am not commenting on whether we should do this in the IETF or not, > I am just stating that we first need to understand what are the needs of > the people that are running these networks. > So, among the things i would like to understnad is that when they say > they need to support intertechnology handovers, whether they need to do > it for any L2 combination, or just a limited/defined set of technologies > that have some special characteristics? >=20 > I think it is relevant to understnad this point in order to understnad > the problem better. =3D> I think the important question to ask is why this is an issue in the first place? If you have a solution for the superset (all link layers) and there is a question about whether you need a solution for a subset, then th= e question we should ask is "why?". This has to be part of the discussion. "w= e want ....*because*..." Hesham=20 >=20 > Regards, marcelo >=20 >=20 > Hesham Soliman escribi=F3: >> A quick comment. >> I don't see any reason for an IETF WG to look for a solution that works = for >> a limited set of technologies and try to solve that on layer 2. This is >> clearly not our job. Similarly, there is little gain in solving this for= a >> limited set of technologies on L3 given that we already have a layer 2 >> agnostic solution. Why would we want to develop another one for a limite= d >> set of link layers? >>=20 >> Hesham >>=20 >>=20 >> On 30/06/09 10:39 PM, "marcelo bagnulo braun" wrote= : >>=20 >> =20 >>> George, >>> =20 >>=20 >>=20 >> great summary >>=20 >> just one comment below... >>=20 >>=20 >> George Tsirtsis >> =20 >>> escribi=F3: >>> With PMIP things are not so clear....it is not even clear we are >>>=20 >>> talking about the *network layer*... and thus it is not so clear how >>>=20 >>> "generic" solutions can be. >>>=20 >>> =20 >>> =20 >> right, so one relevant question is how >> =20 >>> generic we want this to be. >>> =20 >> For instance, it may be also sufficient to support >> =20 >>> inter technology >>> =20 >> handovers for a subset of L2 technologies that can support >> =20 >>> it at the L2=20 >>> =20 >> as you stated. >> So, one thing that we need to define is whether >> =20 >>> we are looking for a >>> =20 >> solution that supports inter technology handover with >> =20 >>> any two L2=20 >>> =20 >> combiantios or are we looking for a solution that supports inter >> =20 >> technology handovers for a limited set of technologies? >> I think this is a key >> =20 >>> requirements that we need to be explicit about. >>> =20 >>=20 >>=20 >> =20 >>> The challenge for the BOF >>> is to throw some light on how PMIP can be >>> compatible with this extended >>> functionality, what type of additional >>> signalling is needed, and at which >>> layer they intend to implement such >>> signalling. Let's see. >>>=20 >>> =20 >>> =20 >>=20 >> while i >> =20 >>> agree with that, i think a first step that this bof needs to >>> =20 >> throw some light >> =20 >>> on is what are the functional requirements for the >>> =20 >> support of the required >> =20 >>> features. I think the previous is a good example >>> =20 >> of one requirement that we >> =20 >>> need to flesh out. There are many others. >>> =20 >>=20 >> Regards, marcelo >>=20 >>=20 >> =20 >>> George >>>=20 >>> On >>> Tue, Jun 30, 2009 at 1:43 AM, Charles E. >>>=20 >>> Perkins wrote: >>> =20 >>> =20 >>>> Hello Basavaraj, >>>>=20 >>>>=20 >>>> =20 >>> Isn't make-before-break a function performed >>> =20 >>>> at the link layer? >>>>=20 >>>> It >>>> =20 >>> certainly isn't PHY, and I wouldn't think it >>> =20 >>>> qualifies as MAC (i.e., it >>>> =20 >>> doesn't control the >>> =20 >>>> device's access to the medium). >>>>=20 >>>> Regards, >>>>=20 >>>> =20 >>> Charlie P. >>> =20 >>>> PS. Which is the proper mailing list for this >>>> =20 >>> discussion? >>> =20 >>>> Basavaraj.Patil@nokia.com wrote: >>>> =20 >>>> =20 >>>>> Hi >>>>> =20 >>> Frank, >>> =20 >>>>> Make-before-break is inherently supported in certain >>>>> =20 >>> technologies such as >>> =20 >>>>> CDMA/WCDMA (which has soft HO features built in). The >>>>> =20 >>> same is not possible >>> =20 >>>>> for example in TDMA (GSM) or OFDMA (802.16e and >>>>> =20 >>> WiFi). 802.16e does have a >>> =20 >>>>> contorted mechansim for achieving the same but >>>>> =20 >>> that's besides the point. >>> =20 >>>>> So IMO it is a capability of the Phy/Mac. >>>>>=20 >>>>> =20 >>> However it is possible to emulate soft-handovers and achieve >>> =20 >>> make-before-break in certain cases. For example it is possible to be >>> =20 >>> simultaneously connected to HSPA and WiFi and accomplish a >>> =20 >>> make-before-break >>> =20 >>>>> HO. I guess the definition of the term depends on an >>>>> =20 >>> access tchnology or >>> =20 >>>>> the >>>>> combination of access technologies in the >>>>> =20 >>> context of a use-case. >>> =20 >>>>> -Raj >>>>>=20 >>>>>=20 >>>>> On 6/29/09 4:36 PM, "ext Frank >>>>> =20 >>> Xia" wrote: >>> =20 >>>>> =20 >>>>> =20 >>>>>> Hi Raj >>>>>>=20 >>>>>>=20 >>>>>> =20 >>> IMHO Make-before-break is not a link-layer technology. >>> =20 >>>>>> , but a concept >>>>>> =20 >>> (or a strategy). Related to the topic we >>> =20 >>>>>> are discussing, making target >>>>>> =20 >>> interface ready before moving >>> =20 >>>>>> traffic to it is kind of >>>>>> =20 >>> make-before-break. >>> =20 >>>>>> BR >>>>>> Frank >>>>>>=20 >>>>>> ----- Original Message >>>>>> =20 >>> ----- >>> =20 >>>>>> From: >>>>>> To: >>>>>> =20 >>> ; ; ; >>> =20 >>> ; >>> =20 >>>>>> Cc: ; >>>>>> =20 >>> >>> =20 >>>>>> Sent: Monday, June 29, 2009 3:43 PM >>>>>> Subject: Re: >>>>>> =20 >>> [netext] [netlmm] NEXTEXT2: first draft of the bof >>> =20 >>> description >>> =20 >>>>>>=20 >>>>>> Hi Frank, >>>>>>=20 >>>>>> Comments >>>>>> =20 >>> inline: >>> =20 >>>>>> On 6/29/09 2:57 PM, "ext Frank Xia" >>>>>> =20 >>> wrote: >>> =20 >>>>>> =20 >>>>>> =20 >>>>>>> Hi >>>>>>> =20 >>> Raj >>> =20 >>>>>>> My main point is make-before-break strategy >>>>>>> is the best >>>>>>> =20 >>> way to solve multi-radio handover. >>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>> The IETF cannot >>>>>> =20 >>> do anything about whether an MN has the ability to >>> =20 >>>>>> accomplish >>>>>> =20 >>> make-before-break connectivity. It depends on the link-layer >>> =20 >>>>>> technology, >>>>>> =20 >>> spectrum that they operate in, etc. So this approach is a >>> =20 >>>>>> non-starter. >>>>>> =20 >>> The IETF solution has to be agnostic to underlying access >>> =20 >>> technologies. >>> =20 >>>>>> =20 >>>>>> =20 >>>>>>> Please see my inline >>>>>>> =20 >>> response. >>> =20 >>>>>>> BR >>>>>>> ----- Original Message ----- >>>>>>> From: >>>>>>> =20 >>> >>> =20 >>>>>>> To: ; >>>>>>> =20 >>> ; ; >>> =20 >>>>>>> ; >>>>>>> =20 >>> >>> =20 >>>>>>> Cc: ; >>>>>>> =20 >>> >>> =20 >>>>>>> Sent: Monday, June 29, 2009 11:50 AM >>>>>>> Subject: >>>>>>> =20 >>> Re: [netlmm] NEXTEXT2: first draft of the bof >>> description >>> =20 >>>>>>>=20 >>>>>>> Frank, >>>>>>>=20 >>>>>>>=20 >>>>>>> On 6/29/09 11:16 >>>>>>> =20 >>> AM, "ext Frank Xia" wrote: >>> =20 >>>>>>>=20 >>>>>>> =20 >>>>>>>> Hi Guys >>>>>>>>=20 >>>>>>>> I have comments on inter-technology >>>>>>>> =20 >>> handover. >>> =20 >>>>>>>> IMHO, flow mobility could solve problems >>>>>>>> which >>>>>>>> =20 >>> inter-tech handover is try to deal with. >>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>> Flow >>>>>>> =20 >>> mobility also includes the ability to move a flow from one mobility >>> =20 >>> session to another. Multiple mobility sessions could be established via >>> =20 >>> a >>> =20 >>>>>>> single interface in which case flow mobility would be achieved >>>>>>> =20 >>> within >>> =20 >>>>>>> the >>>>>>> scope of a single interface. Hence flow mobility and >>>>>>> =20 >>> inter-technology >>> =20 >>>>>>> handovers are separate features. >>>>>>> Frank=3D>IMHO, >>>>>>> =20 >>> inter-technology is trying to move all the traffic on >>> =20 >>>>>>> one interface to >>>>>>> =20 >>> another interface. >>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>> Right. I guess you answered the >>>>>> =20 >>> question about the difference between >>> =20 >>>>>> flow >>>>>> mobility and >>>>>> =20 >>> inter-technology handovers. You could extrapolate and say >>> =20 >>>>>> that >>>>>>=20 >>>>>> =20 >>> inter-technology HO is the case where you move all flows from one >>> =20 >>> interface >>> =20 >>>>>> to another and hence a variant of flow mobility. While that is >>>>>> =20 >>> true, you >>> =20 >>>>>> should also recognize that the granularity of flow mobility is >>>>>> =20 >>> finer and >>> =20 >>>>>> does not have to necessarily be a relocation of a flow between >>>>>> =20 >>> physical >>> =20 >>>>>> interfaces. >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>>>> I assume that two >>>>>>>> =20 >>> heterogeneous interfaces are >>> =20 >>>>>>>> all active during the handover. It is >>>>>>>> =20 >>> easy to move >>> =20 >>>>>>>> a flow(or all flows) from an interface to >>>>>>>> =20 >>> another. >>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>> Possibly.. But the point is to >>>>>>> =20 >>> identify what extensions (possibly to the >>> =20 >>>>>>> MN) >>>>>>> are needed in order >>>>>>> =20 >>> to achieve handovers across interfaces. >>> =20 >>>>>>> Frank=3D>If we see inter-tech >>>>>>> =20 >>> handover as a subset of flow mobility, >>> =20 >>>>>>> there is one problem left, that >>>>>>> =20 >>> is flow mobility. >>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>> See above. Flow mobility is a >>>>>> =20 >>> feature that can work across multiple >>> =20 >>>>>> mobility >>>>>> sessions within the >>>>>> =20 >>> scope of a single interface as well. >>> =20 >>>>>> =20 >>>>>> =20 >>>>>>>> This is >>>>>>>> =20 >>> probably the reason why there is no >>> =20 >>>>>>>> inter-tech handover solution >>>>>>>> =20 >>> standerdized >>> =20 >>>>>>>> for client MIP. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>> Client >>>>>>> =20 >>> MIP inherently supports handovers across multiple interfaces. >>> =20 >>> Performance improvements to the handovers are accomplished using >>> =20 >>> solutions >>> =20 >>>>>>> such as FMIP. >>>>>>> Frank=3D>Maybe, I am missing something. >>>>>>> =20 >>> However FMIP is not applicable >>> =20 >>>>>>> to PAR/NAR collocated scenario. For >>>>>>> =20 >>> example, a mobile node with two >>> =20 >>>>>>> interface connects to the same access >>>>>>> =20 >>> router (ASN-GW for WiMAX, >>> =20 >>>>>>> PDN-GW for LTE). Does FMIP work when mobile >>>>>>> =20 >>> node handover from >>> =20 >>>>>>> one technology to another? >>>>>>>=20 >>>>>>>=20 >>>>>>> =20 >>>>>> Not sure I understand the question. In your example above, I believe >>>>>> =20 >>> the >>> =20 >>>>>> MN >>>>>> would connect to the ASN-GW via the WiMAX interface and to an >>>>>> =20 >>> S-GW via >>> =20 >>>>>> the >>>>>> LTE interface. The P-GW (LMA) may be the same. If the >>>>>> =20 >>> question is, can >>> =20 >>>>>> you >>>>>> use FMIP to optimize handovers in such a >>>>>> =20 >>> scenario... Yes. Not FMIP, but >>> =20 >>>>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't >>>>>> =20 >>> think we are looking at >>> =20 >>>>>> optimizing >>>>>> handovers in this >>>>>> =20 >>> discussion. >>> =20 >>>>>> As per the current PMIP6 specification wherein no changes to >>>>>> =20 >>> the host are >>> =20 >>>>>> required, it is not possible to do an inter-technology >>>>>> =20 >>> handover. This is >>> =20 >>>>>> a >>>>>> limitation which implies that PMIP6 provides >>>>>> =20 >>> host mobility to an MN >>> =20 >>>>>> within >>>>>> the scope of a single access >>>>>> =20 >>> technology. Host based mobile IP does not >>> =20 >>>>>> have >>>>>> this >>>>>> =20 >>> problem. >>> =20 >>>>>> -Raj >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>>> -Raj >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> =20 >>>>>>>> BR >>>>>>>> Frank >>>>>>>>=20 >>>>>>>> ----- Original Message ----- >>>>>>>>=20 >>>>>>>> =20 >>> From: "marcelo bagnulo braun" >>> =20 >>>>>>>> To: >>>>>>>> =20 >>> ; "mext" ; >>> =20 >>>>>>>> Cc: >>>>>>>> =20 >>> ; "Ralph Droms" >>> =20 >>>>>>>> Sent: >>>>>>>> =20 >>> Sunday, June 28, 2009 1:16 PM >>> =20 >>>>>>>> Subject: [netlmm] NEXTEXT2: first draft >>>>>>>> =20 >>> of the bof description >>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> =20 >>> Hi, >>> =20 >>>>>>>>> This is a first draft of the BOF description for your >>>>>>>>> =20 >>> consideration. >>> =20 >>>>>>>>> It >>>>>>>>> is >>>>>>>>> still very open so, feel free to >>>>>>>>> =20 >>> comment on whether the proposed >>> =20 >>>>>>>>> approach >>>>>>>>> seems appropriate or >>>>>>>>> =20 >>> not. >>> =20 >>>>>>>>> NETEXT2 BOF description >>>>>>>>>=20 >>>>>>>>> =20 >>> ----------------------- >>> =20 >>>>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is >>>>>>>>> =20 >>> a network based mobility >>> =20 >>>>>>>>> protocol built on Mobile IPv6 [RFC3775]. >>>>>>>>> =20 >>> PMIP6 provides mobility to >>> =20 >>>>>>>>> IP hosts without requiring any protocol >>>>>>>>> =20 >>> enhancements or additional >>> =20 >>>>>>>>> capabilities on the host. >>>>>>>>> Current >>>>>>>>> =20 >>> PMIP6 specification fully defines how to provide mobility >>> =20 >>>>>>>>> support for >>>>>>>>> =20 >>> mobile nodes with a single interface roaming in a PMIP6 >>> =20 >>>>>>>>> domain. The >>>>>>>>> =20 >>> goal of this BOF is gain understanding of how to support >>> =20 >>>>>>>>> nodes with >>>>>>>>> =20 >>> multiple interfaces (of possible different technologies) in >>> =20 >>>>>>>>> a >>>>>>>>>=20 >>>>>>>>> =20 >>> PMIP6 network. >>> =20 >>>>>>>>> In particular, this BOF assumes the following >>>>>>>>> =20 >>> scenario: >>> =20 >>>>>>>>> We have a single PMIP6 domain that has deployed >>>>>>>>> =20 >>> multiple >>> =20 >>>>>>>>> access technologies and needs to support nodes that >>>>>>>>> =20 >>> have >>> =20 >>>>>>>>> multiple interfaces, possibly of different >>>>>>>>> =20 >>> technologies. >>> =20 >>>>>>>>> In particular, the following capabilities are >>>>>>>>> =20 >>> needed: >>> =20 >>>>>>>>> - Inter-technology handover support. The MN has >>>>>>>>> =20 >>> initiated a >>> =20 >>>>>>>>> communication over one interface and it needs to be able >>>>>>>>> =20 >>> to move >>> =20 >>>>>>>>> the established connection to a different interface of >>>>>>>>>=20 >>>>>>>>> =20 >>> a possibly different technology. The reason for moving >>> =20 >>>>>>>>> the >>>>>>>>> =20 >>> communication to another interface is because of the MNs >>> =20 >>>>>>>>> mobility and >>>>>>>>> =20 >>> attaching via a different interface. Basically >>> =20 >>>>>>>>> the ability to perform >>>>>>>>> =20 >>> handovers that span different access >>> =20 >>>>>>>>> technologies. >>>>>>>>>=20 >>>>>>>>> - >>>>>>>>> =20 >>> Multihoming support. The MN with multiple interfaces of possibly >>> =20 >>> different technologies should be able to use them simultaneously to >>> =20 >>> exchange data and manage the mobility of communications >>> =20 >>>>>>>>> established >>>>>>>>> =20 >>> through the different interfaces. >>> =20 >>>>>>>>> - Flow mobility. A MN with >>>>>>>>> =20 >>> multiple interfaces of possibly >>> =20 >>>>>>>>> different technologies must be able to >>>>>>>>> =20 >>> move a flow from >>> =20 >>>>>>>>> one interface to another. Moreover, the MN should be >>>>>>>>> =20 >>> able >>> =20 >>>>>>>>> to inform the network through which interface it wishes >>>>>>>>>=20 >>>>>>>>> =20 >>> to receive different types of flows. >>> =20 >>>>>>>>> In order to provide the >>>>>>>>> =20 >>> support for these capabilities, different >>> =20 >>>>>>>>> approaches can be >>>>>>>>> =20 >>> envisioned, namely: >>> =20 >>>>>>>>> - L2 only approaches. In this type of approaches, >>>>>>>>> =20 >>> the mechanisms >>> =20 >>>>>>>>> to provide the required capabilities are fully L2 >>>>>>>>> =20 >>> mechanisms and >>> =20 >>>>>>>>> no modification of the IP layer is needed. >>>>>>>>> - L3 >>>>>>>>> =20 >>> only approaches. In this type of approaches, the mechanism to >>> =20 >>>>>>>>> provide >>>>>>>>> =20 >>> to required capabilities are located in the IP layer >>> =20 >>>>>>>>> - Hybrid L2/L3 >>>>>>>>> =20 >>> approaches. In this case, some mechanisms are >>> =20 >>>>>>>>> located in L2 and other >>>>>>>>> =20 >>> mechanisms are located in L3. >>> =20 >>>>>>>>> Now, the different possible approaches >>>>>>>>> =20 >>> vary greatly in their nature >>> =20 >>>>>>>>> and resulting capabilities. To >>>>>>>>> =20 >>> understanding the benefits and >>> =20 >>>>>>>>> suitability of these alternatives, the >>>>>>>>> =20 >>> requirements have to be >>> =20 >>>>>>>>> properly defined and >>>>>>>>> =20 >>> understood. >>> =20 >>>>>>>>> The main goal of the BOF is understanding the need >>>>>>>>> =20 >>> for work in the >>> =20 >>>>>>>>> IETF in this area. In order to do so, during the BOF, >>>>>>>>> =20 >>> we will attempt >>> =20 >>>>>>>>> to: >>>>>>>>>=20 >>>>>>>>> 1) Understand the applicable >>>>>>>>> =20 >>> scenarios, and the problem statement >>> =20 >>>>>>>>> related >>>>>>>>> to >>>>>>>>>=20 >>>>>>>>> =20 >>> those >>> =20 >>>>>>>>> 2) Understand the restrictions and requirement imposed to >>>>>>>>> =20 >>> solutions to >>> =20 >>>>>>>>> address the problem statement and scenarios >>>>>>>>> 3) >>>>>>>>> =20 >>> Get an overview of the proposed solutions >>> =20 >>>>>>>>>=20 >>>>>>>>> =20 >>> _______________________________________________ >>> =20 >>>>>>>>> netlmm mailing >>>>>>>>> =20 >>> list >>> =20 >>>>>>>>> netlmm@ietf.org >>>>>>>>>=20 >>>>>>>>> =20 >>> https://www.ietf.org/mailman/listinfo/netlmm >>> =20 >>>>>>>>> =20 >>>>>>> _______________________________________________ >>>>>>> netext mailing >>>>>>> =20 >>> list >>> =20 >>>>>>> netext@ietf.org >>>>>>>=20 >>>>>>> =20 >>> https://www.ietf.org/mailman/listinfo/netext >>> =20 >>>>>>> =20 >>>>>>> =20 >>> _______________________________________________ >>> =20 >>>>> MEXT mailing list >>>>>=20 >>>>> =20 >>> MEXT@ietf.org >>> =20 >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>> _______________________________________________ >>>> MEXT mailing list >>>>=20 >>>> =20 >>> MEXT@ietf.org >>> =20 >>>> https://www.ietf.org/mailman/listinfo/mext >>>>=20 >>>> =20 >>>> =20 >>> _______________________________________________ >>> netlmm mailing list >>>=20 >>> netlmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/netlmm >>>=20 >>>=20 >>> =20 >>=20 >> _______________________________________________ >> netlmm mailing >> =20 >>> list >>> =20 >> netlmm@ietf.org >> https://www.ietf.org/mailman/listinfo/netlmm >>=20 >>=20 >>=20 >>=20 >> =20 >=20 From terry.l.davis@boeing.com Tue Jun 30 07:34:39 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9695B28C3EB; Tue, 30 Jun 2009 07:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 JlMa1PCfFKOy; Tue, 30 Jun 2009 07:34:38 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 4D66328C3F2; Tue, 30 Jun 2009 07:34:25 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n5UDj79O013326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Jun 2009 08:45:07 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n5UDj7ZI024095; Tue, 30 Jun 2009 08:45:07 -0500 (CDT) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n5UDj64a024057 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 30 Jun 2009 08:45:07 -0500 (CDT) Received: from XCH-NW-CCR1V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Tue, 30 Jun 2009 06:45:07 -0700 From: "Davis, Terry L" To: "'Glen Zorn'" , "Basavaraj.Patil@nokia.com" , "xiayangsong@huawei.com" Date: Tue, 30 Jun 2009 06:45:06 -0700 Thread-Topic: [MEXT] [netext] [netlmm] NEXTEXT2: first draft of thebof description Thread-Index: Acn5Aay986hKNg67SFaq1F9+Bv5PQAAB1ERKAAcyqUAAGAvUYA== Message-ID: <2557049CDBC35B4EBD79CFACFEC045841CCF7146@XCH-NW-CCR1V.nw.nos.boeing.com> References: <00b701c9f901$a61c8420$3e0c7c0a@china.huawei.com> <016901c9f926$d6afaac0$840f0040$@net> In-Reply-To: <016901c9f926$d6afaac0$840f0040$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" , "netlmm@ietf.org" , "netext-chairs@tools.ietf.org" , "mext@ietf.org" Subject: Re: [MEXT] [netext] [netlmm] NEXTEXT2: first draft of thebof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 14:34:39 -0000 Glen Right, cost, weight, and drag, in our case. If you are using links to geos= , it definitely takes two antenna's to do make before break. =20 However a single antenna, as Connexion by Boeing used, can move from one ge= o and lock onto another and have layer 3 routing flowing in well under 30 s= econds; a short enough time that almost none of the TCP timers trigger. Th= e user sees a short "loss of QOS" if they are actively typing or talking wh= ich appears to be no more than a web server not responding for a few second= s or your VoIP losing a few seconds of conversation. As far as aviation goes, you will see both types of handoff's made with a m= ake before break probably more common with air-to-ground links than satelli= te. Coordination capabilities between layer 2 and layer 3 for the handoffs thou= gh are critical. Take care Terry PS: Until the IPSec, PKI, and IKEv2 interoperability between vendors (I mea= n dozens of different vendors!) progresses such that it actually can be dyn= amically done, deciding which security associations belong to which link pr= oviders and auto-configuring the links, I would expect that establishing li= nk authentication and security will remain a primary challenge to mobility = services. > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Glen Zorn > Sent: Monday, June 29, 2009 7:03 PM > To: Basavaraj.Patil@nokia.com; xiayangsong@huawei.com > Cc: netext@ietf.org; netlmm@ietf.org; netext-chairs@tools.ietf.org; > mext@ietf.org > Subject: Re: [MEXT] [netext] [netlmm] NEXTEXT2: first draft of thebof > description >=20 > Basavaraj.Patil@nokia.com writes: >=20 > > Hi Frank, > > > > Make-before-break is inherently supported in certain technologies such > > as > > CDMA/WCDMA (which has soft HO features built in). The same is not > > possible > > for example in TDMA (GSM) or OFDMA (802.16e and WiFi). 802.16e does > > have a > > contorted mechansim for achieving the same but that's besides the > > point. > > So IMO it is a capability of the Phy/Mac. > > However it is possible to emulate soft-handovers and achieve > > make-before-break in certain cases. For example it is possible to be > > simultaneously connected to HSPA and WiFi and accomplish a make-before- > > break > > HO. I guess the definition of the term depends on an access tchnology > > or the > > combination of access technologies in the context of a use-case. >=20 > I'm inclined to agree with you, though isn't the implementation of > make-before-break capability possible using any PHY & dual radios? The > problem being the price of parts... >=20 > ... >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Tue Jun 30 07:57:10 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6FB28C3D5; Tue, 30 Jun 2009 07:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.245 X-Spam-Level: X-Spam-Status: No, score=-6.245 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] 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 Jy2mRxK-gw+b; Tue, 30 Jun 2009 07:57:08 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 1DF9228C3D1; Tue, 30 Jun 2009 07:57:07 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-138.dynamic.orange.es [85.53.138.110]) by smtp03.uc3m.es (Postfix) with ESMTP id 6BE3C72D01F; Tue, 30 Jun 2009 16:46:53 +0200 (CEST) Message-ID: <4A4A255D.3060908@it.uc3m.es> Date: Tue, 30 Jun 2009 16:46:53 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16734.007 Cc: mext , "netlmm@ietf.org" , Basavaraj.Patil@nokia.com Subject: Re: [MEXT] [netlmm] [netext] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 14:57:10 -0000 Hesham Soliman escribió: > > >> I am not commenting on whether we should do this in the IETF or not, >> I am just stating that we first need to understand what are the needs of >> the people that are running these networks. >> So, among the things i would like to understnad is that when they say >> they need to support intertechnology handovers, whether they need to do >> it for any L2 combination, or just a limited/defined set of technologies >> that have some special characteristics? >> >> I think it is relevant to understnad this point in order to understnad >> the problem better. >> > > => I think the important question to ask is why this is an issue in the > first place? If you have a solution for the superset (all link layers) you are assuming and answer here, i.e. that the answer is that the requirement is a subset, which i don't know if it is the case > and > there is a question about whether you need a solution for a subset, then the > question we should ask is "why?". This has to be part of the discussion. "we > want ....*because*..." > > sure, "why?" is a valid question, but before asking ourselves "why?", we need to answer "what?" So, let's first provide an detailed answer of what is being required to support and and that point we will be in good shape to ask "why?" i don't think you can ask "why? until a proper answer has been provide to "what?" agree? Regards, marcelo > Hesham > > >> Regards, marcelo >> >> >> Hesham Soliman escribió: >> >>> A quick comment. >>> I don't see any reason for an IETF WG to look for a solution that works for >>> a limited set of technologies and try to solve that on layer 2. This is >>> clearly not our job. Similarly, there is little gain in solving this for a >>> limited set of technologies on L3 given that we already have a layer 2 >>> agnostic solution. Why would we want to develop another one for a limited >>> set of link layers? >>> >>> Hesham >>> >>> >>> On 30/06/09 10:39 PM, "marcelo bagnulo braun" wrote: >>> >>> >>> >>>> George, >>>> >>>> >>> great summary >>> >>> just one comment below... >>> >>> >>> George Tsirtsis >>> >>> >>>> escribió: >>>> With PMIP things are not so clear....it is not even clear we are >>>> >>>> talking about the *network layer*... and thus it is not so clear how >>>> >>>> "generic" solutions can be. >>>> >>>> >>>> >>>> >>> right, so one relevant question is how >>> >>> >>>> generic we want this to be. >>>> >>>> >>> For instance, it may be also sufficient to support >>> >>> >>>> inter technology >>>> >>>> >>> handovers for a subset of L2 technologies that can support >>> >>> >>>> it at the L2 >>>> >>>> >>> as you stated. >>> So, one thing that we need to define is whether >>> >>> >>>> we are looking for a >>>> >>>> >>> solution that supports inter technology handover with >>> >>> >>>> any two L2 >>>> >>>> >>> combiantios or are we looking for a solution that supports inter >>> >>> technology handovers for a limited set of technologies? >>> I think this is a key >>> >>> >>>> requirements that we need to be explicit about. >>>> >>>> >>> >>> >>>> The challenge for the BOF >>>> is to throw some light on how PMIP can be >>>> compatible with this extended >>>> functionality, what type of additional >>>> signalling is needed, and at which >>>> layer they intend to implement such >>>> signalling. Let's see. >>>> >>>> >>>> >>>> >>> while i >>> >>> >>>> agree with that, i think a first step that this bof needs to >>>> >>>> >>> throw some light >>> >>> >>>> on is what are the functional requirements for the >>>> >>>> >>> support of the required >>> >>> >>>> features. I think the previous is a good example >>>> >>>> >>> of one requirement that we >>> >>> >>>> need to flesh out. There are many others. >>>> >>>> >>> Regards, marcelo >>> >>> >>> >>> >>>> George >>>> >>>> On >>>> Tue, Jun 30, 2009 at 1:43 AM, Charles E. >>>> >>>> Perkins wrote: >>>> >>>> >>>> >>>>> Hello Basavaraj, >>>>> >>>>> >>>>> >>>>> >>>> Isn't make-before-break a function performed >>>> >>>> >>>>> at the link layer? >>>>> >>>>> It >>>>> >>>>> >>>> certainly isn't PHY, and I wouldn't think it >>>> >>>> >>>>> qualifies as MAC (i.e., it >>>>> >>>>> >>>> doesn't control the >>>> >>>> >>>>> device's access to the medium). >>>>> >>>>> Regards, >>>>> >>>>> >>>>> >>>> Charlie P. >>>> >>>> >>>>> PS. Which is the proper mailing list for this >>>>> >>>>> >>>> discussion? >>>> >>>> >>>>> Basavaraj.Patil@nokia.com wrote: >>>>> >>>>> >>>>> >>>>>> Hi >>>>>> >>>>>> >>>> Frank, >>>> >>>> >>>>>> Make-before-break is inherently supported in certain >>>>>> >>>>>> >>>> technologies such as >>>> >>>> >>>>>> CDMA/WCDMA (which has soft HO features built in). The >>>>>> >>>>>> >>>> same is not possible >>>> >>>> >>>>>> for example in TDMA (GSM) or OFDMA (802.16e and >>>>>> >>>>>> >>>> WiFi). 802.16e does have a >>>> >>>> >>>>>> contorted mechansim for achieving the same but >>>>>> >>>>>> >>>> that's besides the point. >>>> >>>> >>>>>> So IMO it is a capability of the Phy/Mac. >>>>>> >>>>>> >>>>>> >>>> However it is possible to emulate soft-handovers and achieve >>>> >>>> make-before-break in certain cases. For example it is possible to be >>>> >>>> simultaneously connected to HSPA and WiFi and accomplish a >>>> >>>> make-before-break >>>> >>>> >>>>>> HO. I guess the definition of the term depends on an >>>>>> >>>>>> >>>> access tchnology or >>>> >>>> >>>>>> the >>>>>> combination of access technologies in the >>>>>> >>>>>> >>>> context of a use-case. >>>> >>>> >>>>>> -Raj >>>>>> >>>>>> >>>>>> On 6/29/09 4:36 PM, "ext Frank >>>>>> >>>>>> >>>> Xia" wrote: >>>> >>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi Raj >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> IMHO Make-before-break is not a link-layer technology. >>>> >>>> >>>>>>> , but a concept >>>>>>> >>>>>>> >>>> (or a strategy). Related to the topic we >>>> >>>> >>>>>>> are discussing, making target >>>>>>> >>>>>>> >>>> interface ready before moving >>>> >>>> >>>>>>> traffic to it is kind of >>>>>>> >>>>>>> >>>> make-before-break. >>>> >>>> >>>>>>> BR >>>>>>> Frank >>>>>>> >>>>>>> ----- Original Message >>>>>>> >>>>>>> >>>> ----- >>>> >>>> >>>>>>> From: >>>>>>> To: >>>>>>> >>>>>>> >>>> ; ; ; >>>> >>>> ; >>>> >>>> >>>>>>> Cc: ; >>>>>>> >>>>>>> >>>> >>>> >>>> >>>>>>> Sent: Monday, June 29, 2009 3:43 PM >>>>>>> Subject: Re: >>>>>>> >>>>>>> >>>> [netext] [netlmm] NEXTEXT2: first draft of the bof >>>> >>>> description >>>> >>>> >>>>>>> Hi Frank, >>>>>>> >>>>>>> Comments >>>>>>> >>>>>>> >>>> inline: >>>> >>>> >>>>>>> On 6/29/09 2:57 PM, "ext Frank Xia" >>>>>>> >>>>>>> >>>> wrote: >>>> >>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> >>>> Raj >>>> >>>> >>>>>>>> My main point is make-before-break strategy >>>>>>>> is the best >>>>>>>> >>>>>>>> >>>> way to solve multi-radio handover. >>>> >>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> The IETF cannot >>>>>>> >>>>>>> >>>> do anything about whether an MN has the ability to >>>> >>>> >>>>>>> accomplish >>>>>>> >>>>>>> >>>> make-before-break connectivity. It depends on the link-layer >>>> >>>> >>>>>>> technology, >>>>>>> >>>>>>> >>>> spectrum that they operate in, etc. So this approach is a >>>> >>>> >>>>>>> non-starter. >>>>>>> >>>>>>> >>>> The IETF solution has to be agnostic to underlying access >>>> >>>> technologies. >>>> >>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Please see my inline >>>>>>>> >>>>>>>> >>>> response. >>>> >>>> >>>>>>>> BR >>>>>>>> ----- Original Message ----- >>>>>>>> From: >>>>>>>> >>>>>>>> >>>> >>>> >>>> >>>>>>>> To: ; >>>>>>>> >>>>>>>> >>>> ; ; >>>> >>>> >>>>>>>> ; >>>>>>>> >>>>>>>> >>>> >>>> >>>> >>>>>>>> Cc: ; >>>>>>>> >>>>>>>> >>>> >>>> >>>> >>>>>>>> Sent: Monday, June 29, 2009 11:50 AM >>>>>>>> Subject: >>>>>>>> >>>>>>>> >>>> Re: [netlmm] NEXTEXT2: first draft of the bof >>>> description >>>> >>>> >>>>>>>> Frank, >>>>>>>> >>>>>>>> >>>>>>>> On 6/29/09 11:16 >>>>>>>> >>>>>>>> >>>> AM, "ext Frank Xia" wrote: >>>> >>>> >>>>>>>> >>>>>>>> >>>>>>>>> Hi Guys >>>>>>>>> >>>>>>>>> I have comments on inter-technology >>>>>>>>> >>>>>>>>> >>>> handover. >>>> >>>> >>>>>>>>> IMHO, flow mobility could solve problems >>>>>>>>> which >>>>>>>>> >>>>>>>>> >>>> inter-tech handover is try to deal with. >>>> >>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Flow >>>>>>>> >>>>>>>> >>>> mobility also includes the ability to move a flow from one mobility >>>> >>>> session to another. Multiple mobility sessions could be established via >>>> >>>> a >>>> >>>> >>>>>>>> single interface in which case flow mobility would be achieved >>>>>>>> >>>>>>>> >>>> within >>>> >>>> >>>>>>>> the >>>>>>>> scope of a single interface. Hence flow mobility and >>>>>>>> >>>>>>>> >>>> inter-technology >>>> >>>> >>>>>>>> handovers are separate features. >>>>>>>> Frank=>IMHO, >>>>>>>> >>>>>>>> >>>> inter-technology is trying to move all the traffic on >>>> >>>> >>>>>>>> one interface to >>>>>>>> >>>>>>>> >>>> another interface. >>>> >>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Right. I guess you answered the >>>>>>> >>>>>>> >>>> question about the difference between >>>> >>>> >>>>>>> flow >>>>>>> mobility and >>>>>>> >>>>>>> >>>> inter-technology handovers. You could extrapolate and say >>>> >>>> >>>>>>> that >>>>>>> >>>>>>> >>>>>>> >>>> inter-technology HO is the case where you move all flows from one >>>> >>>> interface >>>> >>>> >>>>>>> to another and hence a variant of flow mobility. While that is >>>>>>> >>>>>>> >>>> true, you >>>> >>>> >>>>>>> should also recognize that the granularity of flow mobility is >>>>>>> >>>>>>> >>>> finer and >>>> >>>> >>>>>>> does not have to necessarily be a relocation of a flow between >>>>>>> >>>>>>> >>>> physical >>>> >>>> >>>>>>> interfaces. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> I assume that two >>>>>>>>> >>>>>>>>> >>>> heterogeneous interfaces are >>>> >>>> >>>>>>>>> all active during the handover. It is >>>>>>>>> >>>>>>>>> >>>> easy to move >>>> >>>> >>>>>>>>> a flow(or all flows) from an interface to >>>>>>>>> >>>>>>>>> >>>> another. >>>> >>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Possibly.. But the point is to >>>>>>>> >>>>>>>> >>>> identify what extensions (possibly to the >>>> >>>> >>>>>>>> MN) >>>>>>>> are needed in order >>>>>>>> >>>>>>>> >>>> to achieve handovers across interfaces. >>>> >>>> >>>>>>>> Frank=>If we see inter-tech >>>>>>>> >>>>>>>> >>>> handover as a subset of flow mobility, >>>> >>>> >>>>>>>> there is one problem left, that >>>>>>>> >>>>>>>> >>>> is flow mobility. >>>> >>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> See above. Flow mobility is a >>>>>>> >>>>>>> >>>> feature that can work across multiple >>>> >>>> >>>>>>> mobility >>>>>>> sessions within the >>>>>>> >>>>>>> >>>> scope of a single interface as well. >>>> >>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> This is >>>>>>>>> >>>>>>>>> >>>> probably the reason why there is no >>>> >>>> >>>>>>>>> inter-tech handover solution >>>>>>>>> >>>>>>>>> >>>> standerdized >>>> >>>> >>>>>>>>> for client MIP. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Client >>>>>>>> >>>>>>>> >>>> MIP inherently supports handovers across multiple interfaces. >>>> >>>> Performance improvements to the handovers are accomplished using >>>> >>>> solutions >>>> >>>> >>>>>>>> such as FMIP. >>>>>>>> Frank=>Maybe, I am missing something. >>>>>>>> >>>>>>>> >>>> However FMIP is not applicable >>>> >>>> >>>>>>>> to PAR/NAR collocated scenario. For >>>>>>>> >>>>>>>> >>>> example, a mobile node with two >>>> >>>> >>>>>>>> interface connects to the same access >>>>>>>> >>>>>>>> >>>> router (ASN-GW for WiMAX, >>>> >>>> >>>>>>>> PDN-GW for LTE). Does FMIP work when mobile >>>>>>>> >>>>>>>> >>>> node handover from >>>> >>>> >>>>>>>> one technology to another? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Not sure I understand the question. In your example above, I believe >>>>>>> >>>>>>> >>>> the >>>> >>>> >>>>>>> MN >>>>>>> would connect to the ASN-GW via the WiMAX interface and to an >>>>>>> >>>>>>> >>>> S-GW via >>>> >>>> >>>>>>> the >>>>>>> LTE interface. The P-GW (LMA) may be the same. If the >>>>>>> >>>>>>> >>>> question is, can >>>> >>>> >>>>>>> you >>>>>>> use FMIP to optimize handovers in such a >>>>>>> >>>>>>> >>>> scenario... Yes. Not FMIP, but >>>> >>>> >>>>>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't >>>>>>> >>>>>>> >>>> think we are looking at >>>> >>>> >>>>>>> optimizing >>>>>>> handovers in this >>>>>>> >>>>>>> >>>> discussion. >>>> >>>> >>>>>>> As per the current PMIP6 specification wherein no changes to >>>>>>> >>>>>>> >>>> the host are >>>> >>>> >>>>>>> required, it is not possible to do an inter-technology >>>>>>> >>>>>>> >>>> handover. This is >>>> >>>> >>>>>>> a >>>>>>> limitation which implies that PMIP6 provides >>>>>>> >>>>>>> >>>> host mobility to an MN >>>> >>>> >>>>>>> within >>>>>>> the scope of a single access >>>>>>> >>>>>>> >>>> technology. Host based mobile IP does not >>>> >>>> >>>>>>> have >>>>>>> this >>>>>>> >>>>>>> >>>> problem. >>>> >>>> >>>>>>> -Raj >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -Raj >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> BR >>>>>>>>> Frank >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> From: "marcelo bagnulo braun" >>>> >>>> >>>>>>>>> To: >>>>>>>>> >>>>>>>>> >>>> ; "mext" ; >>>> >>>> >>>>>>>>> Cc: >>>>>>>>> >>>>>>>>> >>>> ; "Ralph Droms" >>>> >>>> >>>>>>>>> Sent: >>>>>>>>> >>>>>>>>> >>>> Sunday, June 28, 2009 1:16 PM >>>> >>>> >>>>>>>>> Subject: [netlmm] NEXTEXT2: first draft >>>>>>>>> >>>>>>>>> >>>> of the bof description >>>> >>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> Hi, >>>> >>>> >>>>>>>>>> This is a first draft of the BOF description for your >>>>>>>>>> >>>>>>>>>> >>>> consideration. >>>> >>>> >>>>>>>>>> It >>>>>>>>>> is >>>>>>>>>> still very open so, feel free to >>>>>>>>>> >>>>>>>>>> >>>> comment on whether the proposed >>>> >>>> >>>>>>>>>> approach >>>>>>>>>> seems appropriate or >>>>>>>>>> >>>>>>>>>> >>>> not. >>>> >>>> >>>>>>>>>> NETEXT2 BOF description >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>> ----------------------- >>>> >>>> >>>>>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is >>>>>>>>>> >>>>>>>>>> >>>> a network based mobility >>>> >>>> >>>>>>>>>> protocol built on Mobile IPv6 [RFC3775]. >>>>>>>>>> >>>>>>>>>> >>>> PMIP6 provides mobility to >>>> >>>> >>>>>>>>>> IP hosts without requiring any protocol >>>>>>>>>> >>>>>>>>>> >>>> enhancements or additional >>>> >>>> >>>>>>>>>> capabilities on the host. >>>>>>>>>> Current >>>>>>>>>> >>>>>>>>>> >>>> PMIP6 specification fully defines how to provide mobility >>>> >>>> >>>>>>>>>> support for >>>>>>>>>> >>>>>>>>>> >>>> mobile nodes with a single interface roaming in a PMIP6 >>>> >>>> >>>>>>>>>> domain. The >>>>>>>>>> >>>>>>>>>> >>>> goal of this BOF is gain understanding of how to support >>>> >>>> >>>>>>>>>> nodes with >>>>>>>>>> >>>>>>>>>> >>>> multiple interfaces (of possible different technologies) in >>>> >>>> >>>>>>>>>> a >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>> PMIP6 network. >>>> >>>> >>>>>>>>>> In particular, this BOF assumes the following >>>>>>>>>> >>>>>>>>>> >>>> scenario: >>>> >>>> >>>>>>>>>> We have a single PMIP6 domain that has deployed >>>>>>>>>> >>>>>>>>>> >>>> multiple >>>> >>>> >>>>>>>>>> access technologies and needs to support nodes that >>>>>>>>>> >>>>>>>>>> >>>> have >>>> >>>> >>>>>>>>>> multiple interfaces, possibly of different >>>>>>>>>> >>>>>>>>>> >>>> technologies. >>>> >>>> >>>>>>>>>> In particular, the following capabilities are >>>>>>>>>> >>>>>>>>>> >>>> needed: >>>> >>>> >>>>>>>>>> - Inter-technology handover support. The MN has >>>>>>>>>> >>>>>>>>>> >>>> initiated a >>>> >>>> >>>>>>>>>> communication over one interface and it needs to be able >>>>>>>>>> >>>>>>>>>> >>>> to move >>>> >>>> >>>>>>>>>> the established connection to a different interface of >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>> a possibly different technology. The reason for moving >>>> >>>> >>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> >>>> communication to another interface is because of the MNs >>>> >>>> >>>>>>>>>> mobility and >>>>>>>>>> >>>>>>>>>> >>>> attaching via a different interface. Basically >>>> >>>> >>>>>>>>>> the ability to perform >>>>>>>>>> >>>>>>>>>> >>>> handovers that span different access >>>> >>>> >>>>>>>>>> technologies. >>>>>>>>>> >>>>>>>>>> - >>>>>>>>>> >>>>>>>>>> >>>> Multihoming support. The MN with multiple interfaces of possibly >>>> >>>> different technologies should be able to use them simultaneously to >>>> >>>> exchange data and manage the mobility of communications >>>> >>>> >>>>>>>>>> established >>>>>>>>>> >>>>>>>>>> >>>> through the different interfaces. >>>> >>>> >>>>>>>>>> - Flow mobility. A MN with >>>>>>>>>> >>>>>>>>>> >>>> multiple interfaces of possibly >>>> >>>> >>>>>>>>>> different technologies must be able to >>>>>>>>>> >>>>>>>>>> >>>> move a flow from >>>> >>>> >>>>>>>>>> one interface to another. Moreover, the MN should be >>>>>>>>>> >>>>>>>>>> >>>> able >>>> >>>> >>>>>>>>>> to inform the network through which interface it wishes >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>> to receive different types of flows. >>>> >>>> >>>>>>>>>> In order to provide the >>>>>>>>>> >>>>>>>>>> >>>> support for these capabilities, different >>>> >>>> >>>>>>>>>> approaches can be >>>>>>>>>> >>>>>>>>>> >>>> envisioned, namely: >>>> >>>> >>>>>>>>>> - L2 only approaches. In this type of approaches, >>>>>>>>>> >>>>>>>>>> >>>> the mechanisms >>>> >>>> >>>>>>>>>> to provide the required capabilities are fully L2 >>>>>>>>>> >>>>>>>>>> >>>> mechanisms and >>>> >>>> >>>>>>>>>> no modification of the IP layer is needed. >>>>>>>>>> - L3 >>>>>>>>>> >>>>>>>>>> >>>> only approaches. In this type of approaches, the mechanism to >>>> >>>> >>>>>>>>>> provide >>>>>>>>>> >>>>>>>>>> >>>> to required capabilities are located in the IP layer >>>> >>>> >>>>>>>>>> - Hybrid L2/L3 >>>>>>>>>> >>>>>>>>>> >>>> approaches. In this case, some mechanisms are >>>> >>>> >>>>>>>>>> located in L2 and other >>>>>>>>>> >>>>>>>>>> >>>> mechanisms are located in L3. >>>> >>>> >>>>>>>>>> Now, the different possible approaches >>>>>>>>>> >>>>>>>>>> >>>> vary greatly in their nature >>>> >>>> >>>>>>>>>> and resulting capabilities. To >>>>>>>>>> >>>>>>>>>> >>>> understanding the benefits and >>>> >>>> >>>>>>>>>> suitability of these alternatives, the >>>>>>>>>> >>>>>>>>>> >>>> requirements have to be >>>> >>>> >>>>>>>>>> properly defined and >>>>>>>>>> >>>>>>>>>> >>>> understood. >>>> >>>> >>>>>>>>>> The main goal of the BOF is understanding the need >>>>>>>>>> >>>>>>>>>> >>>> for work in the >>>> >>>> >>>>>>>>>> IETF in this area. In order to do so, during the BOF, >>>>>>>>>> >>>>>>>>>> >>>> we will attempt >>>> >>>> >>>>>>>>>> to: >>>>>>>>>> >>>>>>>>>> 1) Understand the applicable >>>>>>>>>> >>>>>>>>>> >>>> scenarios, and the problem statement >>>> >>>> >>>>>>>>>> related >>>>>>>>>> to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>> those >>>> >>>> >>>>>>>>>> 2) Understand the restrictions and requirement imposed to >>>>>>>>>> >>>>>>>>>> >>>> solutions to >>>> >>>> >>>>>>>>>> address the problem statement and scenarios >>>>>>>>>> 3) >>>>>>>>>> >>>>>>>>>> >>>> Get an overview of the proposed solutions >>>> >>>> >>>>>>>>>> >>>>>>>>>> >>>> _______________________________________________ >>>> >>>> >>>>>>>>>> netlmm mailing >>>>>>>>>> >>>>>>>>>> >>>> list >>>> >>>> >>>>>>>>>> netlmm@ietf.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>> https://www.ietf.org/mailman/listinfo/netlmm >>>> >>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> netext mailing >>>>>>>> >>>>>>>> >>>> list >>>> >>>> >>>>>>>> netext@ietf.org >>>>>>>> >>>>>>>> >>>>>>>> >>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>> _______________________________________________ >>>> >>>> >>>>>> MEXT mailing list >>>>>> >>>>>> >>>>>> >>>> MEXT@ietf.org >>>> >>>> >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> >>>>> >>>>> >>>> MEXT@ietf.org >>>> >>>> >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> netlmm mailing list >>>> >>>> netlmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netlmm >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> netlmm mailing >>> >>> >>>> list >>>> >>>> >>> netlmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/netlmm >>> >>> >>> >>> >>> >>> > > > > From xiayangsong@huawei.com Tue Jun 30 08:13:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D29C28C3C4; Tue, 30 Jun 2009 08:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_42=0.6, RDNS_NONE=0.1] 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 FDKZpM33Oa9Q; Tue, 30 Jun 2009 08:13:27 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E38FF3A6808; Tue, 30 Jun 2009 08:13:26 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM20067Y4UI1S@szxga03-in.huawei.com>; Tue, 30 Jun 2009 23:11:07 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM200H6O4UIJL@szxga03-in.huawei.com>; Tue, 30 Jun 2009 23:11:06 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM200AAB4UA2P@szxml06-in.huawei.com>; Tue, 30 Jun 2009 23:11:06 +0800 (CST) Date: Tue, 30 Jun 2009 10:10:57 -0500 From: Frank Xia To: marcelo bagnulo braun , Hesham Soliman Message-id: <010b01c9f994$fd1e0990$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=response Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A4A132A.3010307@it.uc3m.es> Cc: Basavaraj.Patil@nokia.com, netlmm@ietf.org, mext Subject: Re: [MEXT] [netlmm] [netext] NEXTEXT2: first draft of the bofdescription X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 15:13:29 -0000 Hi Marcelo I agree that we should make sure business requirements before talking about solutions whether they are based on inter-tech handover, flow binding, layer 2, or layer 3. Tentatively, I prepared the following use cases: 1)Michael has a 3GPP&WiFi terminal. At first, Michael uses 3GPP access for p2p download and VoIP call 2)Then Michael gets into his home where WiFi access is available. Michael prefers running p2p download through WiFi, and leaving the VoIP call still on 3GPP networks. 3)After a while, Michael moves out of his home and loses the WiFi connectivity. All the services through the WiFi access need to be moved back to the 3GPP access which is the only access available. BR Frank ----- Original Message ----- From: "marcelo bagnulo braun" To: "Hesham Soliman" Cc: "mext" ; ; Sent: Tuesday, June 30, 2009 8:29 AM Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bofdescription Hesham, I am not commenting on whether we should do this in the IETF or not, I am just stating that we first need to understand what are the needs of the people that are running these networks. So, among the things i would like to understnad is that when they say they need to support intertechnology handovers, whether they need to do it for any L2 combination, or just a limited/defined set of technologies that have some special characteristics? I think it is relevant to understnad this point in order to understnad the problem better. Regards, marcelo Hesham Soliman escribió: > A quick comment. I don't see any reason for an IETF WG to look for a > solution that works for > a limited set of technologies and try to solve that on layer 2. This is > clearly not our job. Similarly, there is little gain in solving this for a > limited set of technologies on L3 given that we already have a layer 2 > agnostic solution. Why would we want to develop another one for a limited > set of link layers? > > Hesham > > > On 30/06/09 10:39 PM, "marcelo bagnulo braun" wrote: > > >> George, >> > > > great summary > > just one comment below... > > > George Tsirtsis > >> escribió: >> With PMIP things are not so clear....it is not even clear we are >> >> talking about the *network layer*... and thus it is not so clear how >> >> "generic" solutions can be. >> >> > right, so one relevant question is how > >> generic we want this to be. >> > For instance, it may be also sufficient to support > >> inter technology > handovers for a subset of L2 technologies that can support > >> it at the L2 > as you stated. > So, one thing that we need to define is whether > >> we are looking for a > solution that supports inter technology handover with > >> any two L2 > combiantios or are we looking for a solution that supports inter > technology handovers for a limited set of technologies? > I think this is a key > >> requirements that we need to be explicit about. >> > > > >> The challenge for the BOF >> is to throw some light on how PMIP can be >> compatible with this extended >> functionality, what type of additional >> signalling is needed, and at which >> layer they intend to implement such >> signalling. Let's see. >> >> > > while i > >> agree with that, i think a first step that this bof needs to > throw some light > >> on is what are the functional requirements for the > support of the required > >> features. I think the previous is a good example > of one requirement that we > >> need to flesh out. There are many others. >> > > Regards, marcelo > > > >> George >> >> On >> Tue, Jun 30, 2009 at 1:43 AM, Charles E. >> >> Perkins wrote: >> >>> Hello Basavaraj, >>> >>> >>> >> Isn't make-before-break a function performed >> >>> at the link layer? >>> >>> It >>> >> certainly isn't PHY, and I wouldn't think it >> >>> qualifies as MAC (i.e., it >>> >> doesn't control the >> >>> device's access to the medium). >>> >>> Regards, >>> >>> >> Charlie P. >> >>> PS. Which is the proper mailing list for this >>> >> discussion? >> >>> Basavaraj.Patil@nokia.com wrote: >>> >>>> Hi >>>> >> Frank, >> >>>> Make-before-break is inherently supported in certain >>>> >> technologies such as >> >>>> CDMA/WCDMA (which has soft HO features built in). The >>>> >> same is not possible >> >>>> for example in TDMA (GSM) or OFDMA (802.16e and >>>> >> WiFi). 802.16e does have a >> >>>> contorted mechansim for achieving the same but >>>> >> that's besides the point. >> >>>> So IMO it is a capability of the Phy/Mac. >>>> >>>> >> However it is possible to emulate soft-handovers and achieve >> make-before-break in certain cases. For example it is possible to be >> simultaneously connected to HSPA and WiFi and accomplish a >> make-before-break >> >>>> HO. I guess the definition of the term depends on an >>>> >> access tchnology or >> >>>> the >>>> combination of access technologies in the >>>> >> context of a use-case. >> >>>> -Raj >>>> >>>> >>>> On 6/29/09 4:36 PM, "ext Frank >>>> >> Xia" wrote: >> >>>> >>>>> Hi Raj >>>>> >>>>> >>>>> >> IMHO Make-before-break is not a link-layer technology. >> >>>>> , but a concept >>>>> >> (or a strategy). Related to the topic we >> >>>>> are discussing, making target >>>>> >> interface ready before moving >> >>>>> traffic to it is kind of >>>>> >> make-before-break. >> >>>>> BR >>>>> Frank >>>>> >>>>> ----- Original Message >>>>> >> ----- >> >>>>> From: >>>>> To: >>>>> >> ; ; ; >> ; >> >>>>> Cc: ; >>>>> >> >> >>>>> Sent: Monday, June 29, 2009 3:43 PM >>>>> Subject: Re: >>>>> >> [netext] [netlmm] NEXTEXT2: first draft of the bof >> description >> >>>>> >>>>> Hi Frank, >>>>> >>>>> Comments >>>>> >> inline: >> >>>>> On 6/29/09 2:57 PM, "ext Frank Xia" >>>>> >> wrote: >> >>>>> >>>>>> Hi >>>>>> >> Raj >> >>>>>> My main point is make-before-break strategy >>>>>> is the best >>>>>> >> way to solve multi-radio handover. >> >>>>>> >>>>> The IETF cannot >>>>> >> do anything about whether an MN has the ability to >> >>>>> accomplish >>>>> >> make-before-break connectivity. It depends on the link-layer >> >>>>> technology, >>>>> >> spectrum that they operate in, etc. So this approach is a >> >>>>> non-starter. >>>>> >> The IETF solution has to be agnostic to underlying access >> technologies. >> >>>>> >>>>>> Please see my inline >>>>>> >> response. >> >>>>>> BR >>>>>> ----- Original Message ----- >>>>>> From: >>>>>> >> >> >>>>>> To: ; >>>>>> >> ; ; >> >>>>>> ; >>>>>> >> >> >>>>>> Cc: ; >>>>>> >> >> >>>>>> Sent: Monday, June 29, 2009 11:50 AM >>>>>> Subject: >>>>>> >> Re: [netlmm] NEXTEXT2: first draft of the bof >> description >> >>>>>> >>>>>> Frank, >>>>>> >>>>>> >>>>>> On 6/29/09 11:16 >>>>>> >> AM, "ext Frank Xia" wrote: >> >>>>>> >>>>>> >>>>>>> Hi Guys >>>>>>> >>>>>>> I have comments on inter-technology >>>>>>> >> handover. >> >>>>>>> IMHO, flow mobility could solve problems >>>>>>> which >>>>>>> >> inter-tech handover is try to deal with. >> >>>>>>> >>>>>> Flow >>>>>> >> mobility also includes the ability to move a flow from one mobility >> session to another. Multiple mobility sessions could be established >> via >> a >> >>>>>> single interface in which case flow mobility would be achieved >>>>>> >> within >> >>>>>> the >>>>>> scope of a single interface. Hence flow mobility and >>>>>> >> inter-technology >> >>>>>> handovers are separate features. >>>>>> Frank=>IMHO, >>>>>> >> inter-technology is trying to move all the traffic on >> >>>>>> one interface to >>>>>> >> another interface. >> >>>>>> >>>>> Right. I guess you answered the >>>>> >> question about the difference between >> >>>>> flow >>>>> mobility and >>>>> >> inter-technology handovers. You could extrapolate and say >> >>>>> that >>>>> >>>>> >> inter-technology HO is the case where you move all flows from one >> interface >> >>>>> to another and hence a variant of flow mobility. While that is >>>>> >> true, you >> >>>>> should also recognize that the granularity of flow mobility is >>>>> >> finer and >> >>>>> does not have to necessarily be a relocation of a flow between >>>>> >> physical >> >>>>> interfaces. >>>>> >>>>> >>>>>>> I assume that two >>>>>>> >> heterogeneous interfaces are >> >>>>>>> all active during the handover. It is >>>>>>> >> easy to move >> >>>>>>> a flow(or all flows) from an interface to >>>>>>> >> another. >> >>>>>>> >>>>>> Possibly.. But the point is to >>>>>> >> identify what extensions (possibly to the >> >>>>>> MN) >>>>>> are needed in order >>>>>> >> to achieve handovers across interfaces. >> >>>>>> Frank=>If we see inter-tech >>>>>> >> handover as a subset of flow mobility, >> >>>>>> there is one problem left, that >>>>>> >> is flow mobility. >> >>>>>> >>>>> See above. Flow mobility is a >>>>> >> feature that can work across multiple >> >>>>> mobility >>>>> sessions within the >>>>> >> scope of a single interface as well. >> >>>>> >>>>>>> This is >>>>>>> >> probably the reason why there is no >> >>>>>>> inter-tech handover solution >>>>>>> >> standerdized >> >>>>>>> for client MIP. >>>>>>> >>>>>>> >>>>>> Client >>>>>> >> MIP inherently supports handovers across multiple interfaces. >> Performance improvements to the handovers are accomplished using >> solutions >> >>>>>> such as FMIP. >>>>>> Frank=>Maybe, I am missing something. >>>>>> >> However FMIP is not applicable >> >>>>>> to PAR/NAR collocated scenario. For >>>>>> >> example, a mobile node with two >> >>>>>> interface connects to the same access >>>>>> >> router (ASN-GW for WiMAX, >> >>>>>> PDN-GW for LTE). Does FMIP work when mobile >>>>>> >> node handover from >> >>>>>> one technology to another? >>>>>> >>>>>> >>>>>> >>>>> Not sure I understand the question. In your example above, I believe >>>>> >> the >> >>>>> MN >>>>> would connect to the ASN-GW via the WiMAX interface and to an >>>>> >> S-GW via >> >>>>> the >>>>> LTE interface. The P-GW (LMA) may be the same. If the >>>>> >> question is, can >> >>>>> you >>>>> use FMIP to optimize handovers in such a >>>>> >> scenario... Yes. Not FMIP, but >> >>>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't >>>>> >> think we are looking at >> >>>>> optimizing >>>>> handovers in this >>>>> >> discussion. >> >>>>> As per the current PMIP6 specification wherein no changes to >>>>> >> the host are >> >>>>> required, it is not possible to do an inter-technology >>>>> >> handover. This is >> >>>>> a >>>>> limitation which implies that PMIP6 provides >>>>> >> host mobility to an MN >> >>>>> within >>>>> the scope of a single access >>>>> >> technology. Host based mobile IP does not >> >>>>> have >>>>> this >>>>> >> problem. >> >>>>> -Raj >>>>> >>>>> >>>>> >>>>>> -Raj >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> BR >>>>>>> Frank >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> >>>>>>> >> From: "marcelo bagnulo braun" >> >>>>>>> To: >>>>>>> >> ; "mext" ; >> >>>>>>> Cc: >>>>>>> >> ; "Ralph Droms" >> >>>>>>> Sent: >>>>>>> >> Sunday, June 28, 2009 1:16 PM >> >>>>>>> Subject: [netlmm] NEXTEXT2: first draft >>>>>>> >> of the bof description >> >>>>>>> >>>>>>> >> Hi, >> >>>>>>>> This is a first draft of the BOF description for your >>>>>>>> >> consideration. >> >>>>>>>> It >>>>>>>> is >>>>>>>> still very open so, feel free to >>>>>>>> >> comment on whether the proposed >> >>>>>>>> approach >>>>>>>> seems appropriate or >>>>>>>> >> not. >> >>>>>>>> NETEXT2 BOF description >>>>>>>> >>>>>>>> >> ----------------------- >> >>>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is >>>>>>>> >> a network based mobility >> >>>>>>>> protocol built on Mobile IPv6 [RFC3775]. >>>>>>>> >> PMIP6 provides mobility to >> >>>>>>>> IP hosts without requiring any protocol >>>>>>>> >> enhancements or additional >> >>>>>>>> capabilities on the host. >>>>>>>> Current >>>>>>>> >> PMIP6 specification fully defines how to provide mobility >> >>>>>>>> support for >>>>>>>> >> mobile nodes with a single interface roaming in a PMIP6 >> >>>>>>>> domain. The >>>>>>>> >> goal of this BOF is gain understanding of how to support >> >>>>>>>> nodes with >>>>>>>> >> multiple interfaces (of possible different technologies) in >> >>>>>>>> a >>>>>>>> >>>>>>>> >> PMIP6 network. >> >>>>>>>> In particular, this BOF assumes the following >>>>>>>> >> scenario: >> >>>>>>>> We have a single PMIP6 domain that has deployed >>>>>>>> >> multiple >> >>>>>>>> access technologies and needs to support nodes that >>>>>>>> >> have >> >>>>>>>> multiple interfaces, possibly of different >>>>>>>> >> technologies. >> >>>>>>>> In particular, the following capabilities are >>>>>>>> >> needed: >> >>>>>>>> - Inter-technology handover support. The MN has >>>>>>>> >> initiated a >> >>>>>>>> communication over one interface and it needs to be able >>>>>>>> >> to move >> >>>>>>>> the established connection to a different interface of >>>>>>>> >>>>>>>> >> a possibly different technology. The reason for moving >> >>>>>>>> the >>>>>>>> >> communication to another interface is because of the MNs >> >>>>>>>> mobility and >>>>>>>> >> attaching via a different interface. Basically >> >>>>>>>> the ability to perform >>>>>>>> >> handovers that span different access >> >>>>>>>> technologies. >>>>>>>> >>>>>>>> - >>>>>>>> >> Multihoming support. The MN with multiple interfaces of possibly >> different technologies should be able to use them simultaneously to >> exchange data and manage the mobility of communications >> >>>>>>>> established >>>>>>>> >> through the different interfaces. >> >>>>>>>> - Flow mobility. A MN with >>>>>>>> >> multiple interfaces of possibly >> >>>>>>>> different technologies must be able to >>>>>>>> >> move a flow from >> >>>>>>>> one interface to another. Moreover, the MN should be >>>>>>>> >> able >> >>>>>>>> to inform the network through which interface it wishes >>>>>>>> >>>>>>>> >> to receive different types of flows. >> >>>>>>>> In order to provide the >>>>>>>> >> support for these capabilities, different >> >>>>>>>> approaches can be >>>>>>>> >> envisioned, namely: >> >>>>>>>> - L2 only approaches. In this type of approaches, >>>>>>>> >> the mechanisms >> >>>>>>>> to provide the required capabilities are fully L2 >>>>>>>> >> mechanisms and >> >>>>>>>> no modification of the IP layer is needed. >>>>>>>> - L3 >>>>>>>> >> only approaches. In this type of approaches, the mechanism to >> >>>>>>>> provide >>>>>>>> >> to required capabilities are located in the IP layer >> >>>>>>>> - Hybrid L2/L3 >>>>>>>> >> approaches. In this case, some mechanisms are >> >>>>>>>> located in L2 and other >>>>>>>> >> mechanisms are located in L3. >> >>>>>>>> Now, the different possible approaches >>>>>>>> >> vary greatly in their nature >> >>>>>>>> and resulting capabilities. To >>>>>>>> >> understanding the benefits and >> >>>>>>>> suitability of these alternatives, the >>>>>>>> >> requirements have to be >> >>>>>>>> properly defined and >>>>>>>> >> understood. >> >>>>>>>> The main goal of the BOF is understanding the need >>>>>>>> >> for work in the >> >>>>>>>> IETF in this area. In order to do so, during the BOF, >>>>>>>> >> we will attempt >> >>>>>>>> to: >>>>>>>> >>>>>>>> 1) Understand the applicable >>>>>>>> >> scenarios, and the problem statement >> >>>>>>>> related >>>>>>>> to >>>>>>>> >>>>>>>> >> those >> >>>>>>>> 2) Understand the restrictions and requirement imposed to >>>>>>>> >> solutions to >> >>>>>>>> address the problem statement and scenarios >>>>>>>> 3) >>>>>>>> >> Get an overview of the proposed solutions >> >>>>>>>> >>>>>>>> >> _______________________________________________ >> >>>>>>>> netlmm mailing >>>>>>>> >> list >> >>>>>>>> netlmm@ietf.org >>>>>>>> >>>>>>>> >> https://www.ietf.org/mailman/listinfo/netlmm >> >>>>>>>> >>>>>> _______________________________________________ >>>>>> netext mailing >>>>>> >> list >> >>>>>> netext@ietf.org >>>>>> >>>>>> >> https://www.ietf.org/mailman/listinfo/netext >> >>>>>> >> _______________________________________________ >> >>>> MEXT mailing list >>>> >>>> >> MEXT@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> MEXT mailing list >>> >>> >> MEXT@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >> _______________________________________________ >> netlmm mailing list >> >> netlmm@ietf.org >> https://www.ietf.org/mailman/listinfo/netlmm >> >> >> > > _______________________________________________ > netlmm mailing > >> list >> > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm > > > > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www.ietf.org/mailman/listinfo/netlmm From hesham@elevatemobile.com Tue Jun 30 08:27:36 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A53C28C402; Tue, 30 Jun 2009 08:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=-1.057, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, MIME_QP_LONG_LINE=1.396] 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 0ZoqmOkQBpso; Tue, 30 Jun 2009 08:27:33 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 91EBB28C401; Tue, 30 Jun 2009 08:27:31 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MLejE-0004IH-1Q; Wed, 01 Jul 2009 00:54:38 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 01 Jul 2009 00:54:25 +1000 From: Hesham Soliman To: marcelo bagnulo braun Message-ID: Thread-Topic: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description Thread-Index: Acn5kqjXH9wejvH2ykym7Pqo3qqaXg== In-Reply-To: <4A4A255D.3060908@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext , "netlmm@ietf.org" , Basavaraj.Patil@nokia.com Subject: Re: [MEXT] [netlmm] [netext] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 15:27:36 -0000 >>=20 >> =3D> I think the important question to ask is why this is an issue in the >> first place? If you have a solution for the superset (all link layers) > you are assuming and answer here, i.e. that the answer is that the > requirement is a subset, which i don't know if it is the case >=20 >> and >> there is a question about whether you need a solution for a subset, then= the >> question we should ask is "why?". This has to be part of the discussion.= "we >> want ....*because*..." >>=20 >> =20 > sure, "why?" is a valid question, but before asking ourselves "why?", we > need to answer "what?" >=20 > So, let's first provide an detailed answer of what is being required to > support and and that point we will be in good shape to ask "why?" > i don't think you can ask "why? until a proper answer has been provide > to "what?" >=20 > agree? =3D> Ok, you're right about my assumption about the answer but it's not comin= g from vaccuum :), it's not the first time this is discussed. But ok, I'm happy to go through this exercise from the beginning. Let's ask "what" and regardless of the answer ask "why" as well. Because requirements always nee= d to be justified.=20 Hesham >=20 > Regards, marcelo >=20 >> Hesham=20 >>=20 >> =20 >>> Regards, marcelo >>>=20 >>>=20 >>> Hesham Soliman escribi=F3: >>> =20 >>>> A quick comment. >>>> I don't see any reason for an IETF WG to look for a solution that work= s for >>>> a limited set of technologies and try to solve that on layer 2. This i= s >>>> clearly not our job. Similarly, there is little gain in solving this f= or a >>>> limited set of technologies on L3 given that we already have a layer 2 >>>> agnostic solution. Why would we want to develop another one for a limi= ted >>>> set of link layers? >>>>=20 >>>> Hesham >>>>=20 >>>>=20 >>>> On 30/06/09 10:39 PM, "marcelo bagnulo braun" wro= te: >>>>=20 >>>> =20 >>>> =20 >>>>> George, >>>>> =20 >>>>> =20 >>>> great summary >>>>=20 >>>> just one comment below... >>>>=20 >>>>=20 >>>> George Tsirtsis >>>> =20 >>>> =20 >>>>> escribi=F3: >>>>> With PMIP things are not so clear....it is not even clear we are >>>>>=20 >>>>> talking about the *network layer*... and thus it is not so clear how >>>>>=20 >>>>> "generic" solutions can be. >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> right, so one relevant question is how >>>> =20 >>>> =20 >>>>> generic we want this to be. >>>>> =20 >>>>> =20 >>>> For instance, it may be also sufficient to support >>>> =20 >>>> =20 >>>>> inter technology >>>>> =20 >>>>> =20 >>>> handovers for a subset of L2 technologies that can support >>>> =20 >>>> =20 >>>>> it at the L2=20 >>>>> =20 >>>>> =20 >>>> as you stated. >>>> So, one thing that we need to define is whether >>>> =20 >>>> =20 >>>>> we are looking for a >>>>> =20 >>>>> =20 >>>> solution that supports inter technology handover with >>>> =20 >>>> =20 >>>>> any two L2=20 >>>>> =20 >>>>> =20 >>>> combiantios or are we looking for a solution that supports inter >>>> =20 >>>> technology handovers for a limited set of technologies? >>>> I think this is a key >>>> =20 >>>> =20 >>>>> requirements that we need to be explicit about. >>>>> =20 >>>>> =20 >>>> =20 >>>> =20 >>>>> The challenge for the BOF >>>>> is to throw some light on how PMIP can be >>>>> compatible with this extended >>>>> functionality, what type of additional >>>>> signalling is needed, and at which >>>>> layer they intend to implement such >>>>> signalling. Let's see. >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> while i >>>> =20 >>>> =20 >>>>> agree with that, i think a first step that this bof needs to >>>>> =20 >>>>> =20 >>>> throw some light >>>> =20 >>>> =20 >>>>> on is what are the functional requirements for the >>>>> =20 >>>>> =20 >>>> support of the required >>>> =20 >>>> =20 >>>>> features. I think the previous is a good example >>>>> =20 >>>>> =20 >>>> of one requirement that we >>>> =20 >>>> =20 >>>>> need to flesh out. There are many others. >>>>> =20 >>>>> =20 >>>> Regards, marcelo >>>>=20 >>>>=20 >>>> =20 >>>> =20 >>>>> George >>>>>=20 >>>>> On >>>>> Tue, Jun 30, 2009 at 1:43 AM, Charles E. >>>>>=20 >>>>> Perkins wrote: >>>>> =20 >>>>> =20 >>>>> =20 >>>>>> Hello Basavaraj, >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>> Isn't make-before-break a function performed >>>>> =20 >>>>> =20 >>>>>> at the link layer? >>>>>>=20 >>>>>> It >>>>>> =20 >>>>>> =20 >>>>> certainly isn't PHY, and I wouldn't think it >>>>> =20 >>>>> =20 >>>>>> qualifies as MAC (i.e., it >>>>>> =20 >>>>>> =20 >>>>> doesn't control the >>>>> =20 >>>>> =20 >>>>>> device's access to the medium). >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>> Charlie P. >>>>> =20 >>>>> =20 >>>>>> PS. Which is the proper mailing list for this >>>>>> =20 >>>>>> =20 >>>>> discussion? >>>>> =20 >>>>> =20 >>>>>> Basavaraj.Patil@nokia.com wrote: >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>>> Hi >>>>>>> =20 >>>>>>> =20 >>>>> Frank, >>>>> =20 >>>>> =20 >>>>>>> Make-before-break is inherently supported in certain >>>>>>> =20 >>>>>>> =20 >>>>> technologies such as >>>>> =20 >>>>> =20 >>>>>>> CDMA/WCDMA (which has soft HO features built in). The >>>>>>> =20 >>>>>>> =20 >>>>> same is not possible >>>>> =20 >>>>> =20 >>>>>>> for example in TDMA (GSM) or OFDMA (802.16e and >>>>>>> =20 >>>>>>> =20 >>>>> WiFi). 802.16e does have a >>>>> =20 >>>>> =20 >>>>>>> contorted mechansim for achieving the same but >>>>>>> =20 >>>>>>> =20 >>>>> that's besides the point. >>>>> =20 >>>>> =20 >>>>>>> So IMO it is a capability of the Phy/Mac. >>>>>>>=20 >>>>>>> =20 >>>>>>> =20 >>>>> However it is possible to emulate soft-handovers and achieve >>>>> =20 >>>>> make-before-break in certain cases. For example it is possible to be >>>>> =20 >>>>> simultaneously connected to HSPA and WiFi and accomplish a >>>>> =20 >>>>> make-before-break >>>>> =20 >>>>> =20 >>>>>>> HO. I guess the definition of the term depends on an >>>>>>> =20 >>>>>>> =20 >>>>> access tchnology or >>>>> =20 >>>>> =20 >>>>>>> the >>>>>>> combination of access technologies in the >>>>>>> =20 >>>>>>> =20 >>>>> context of a use-case. >>>>> =20 >>>>> =20 >>>>>>> -Raj >>>>>>>=20 >>>>>>>=20 >>>>>>> On 6/29/09 4:36 PM, "ext Frank >>>>>>> =20 >>>>>>> =20 >>>>> Xia" wrote: >>>>> =20 >>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>>> Hi Raj >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> =20 >>>>> IMHO Make-before-break is not a link-layer technology. >>>>> =20 >>>>> =20 >>>>>>>> , but a concept >>>>>>>> =20 >>>>>>>> =20 >>>>> (or a strategy). Related to the topic we >>>>> =20 >>>>> =20 >>>>>>>> are discussing, making target >>>>>>>> =20 >>>>>>>> =20 >>>>> interface ready before moving >>>>> =20 >>>>> =20 >>>>>>>> traffic to it is kind of >>>>>>>> =20 >>>>>>>> =20 >>>>> make-before-break. >>>>> =20 >>>>> =20 >>>>>>>> BR >>>>>>>> Frank >>>>>>>>=20 >>>>>>>> ----- Original Message >>>>>>>> =20 >>>>>>>> =20 >>>>> ----- >>>>> =20 >>>>> =20 >>>>>>>> From: >>>>>>>> To: >>>>>>>> =20 >>>>>>>> =20 >>>>> ; ; ; >>>>> =20 >>>>> ; >>>>> =20 >>>>> =20 >>>>>>>> Cc: ; >>>>>>>> =20 >>>>>>>> =20 >>>>> >>>>> =20 >>>>> =20 >>>>>>>> Sent: Monday, June 29, 2009 3:43 PM >>>>>>>> Subject: Re: >>>>>>>> =20 >>>>>>>> =20 >>>>> [netext] [netlmm] NEXTEXT2: first draft of the bof >>>>> =20 >>>>> description >>>>> =20 >>>>> =20 >>>>>>>> Hi Frank, >>>>>>>>=20 >>>>>>>> Comments >>>>>>>> =20 >>>>>>>> =20 >>>>> inline: >>>>> =20 >>>>> =20 >>>>>>>> On 6/29/09 2:57 PM, "ext Frank Xia" >>>>>>>> =20 >>>>>>>> =20 >>>>> wrote: >>>>> =20 >>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>>> Hi >>>>>>>>> =20 >>>>>>>>> =20 >>>>> Raj >>>>> =20 >>>>> =20 >>>>>>>>> My main point is make-before-break strategy >>>>>>>>> is the best >>>>>>>>> =20 >>>>>>>>> =20 >>>>> way to solve multi-radio handover. >>>>> =20 >>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>> The IETF cannot >>>>>>>> =20 >>>>>>>> =20 >>>>> do anything about whether an MN has the ability to >>>>> =20 >>>>> =20 >>>>>>>> accomplish >>>>>>>> =20 >>>>>>>> =20 >>>>> make-before-break connectivity. It depends on the link-layer >>>>> =20 >>>>> =20 >>>>>>>> technology, >>>>>>>> =20 >>>>>>>> =20 >>>>> spectrum that they operate in, etc. So this approach is a >>>>> =20 >>>>> =20 >>>>>>>> non-starter. >>>>>>>> =20 >>>>>>>> =20 >>>>> The IETF solution has to be agnostic to underlying access >>>>> =20 >>>>> technologies. >>>>> =20 >>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>>> Please see my inline >>>>>>>>> =20 >>>>>>>>> =20 >>>>> response. >>>>> =20 >>>>> =20 >>>>>>>>> BR >>>>>>>>> ----- Original Message ----- >>>>>>>>> From: >>>>>>>>> =20 >>>>>>>>> =20 >>>>> >>>>> =20 >>>>> =20 >>>>>>>>> To: ; >>>>>>>>> =20 >>>>>>>>> =20 >>>>> ; ; >>>>> =20 >>>>> =20 >>>>>>>>> ; >>>>>>>>> =20 >>>>>>>>> =20 >>>>> >>>>> =20 >>>>> =20 >>>>>>>>> Cc: ; >>>>>>>>> =20 >>>>>>>>> =20 >>>>> >>>>> =20 >>>>> =20 >>>>>>>>> Sent: Monday, June 29, 2009 11:50 AM >>>>>>>>> Subject: >>>>>>>>> =20 >>>>>>>>> =20 >>>>> Re: [netlmm] NEXTEXT2: first draft of the bof >>>>> description >>>>> =20 >>>>> =20 >>>>>>>>> Frank, >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 6/29/09 11:16 >>>>>>>>> =20 >>>>>>>>> =20 >>>>> AM, "ext Frank Xia" wrote: >>>>> =20 >>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>>> Hi Guys >>>>>>>>>>=20 >>>>>>>>>> I have comments on inter-technology >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>> handover. >>>>> =20 >>>>> =20 >>>>>>>>>> IMHO, flow mobility could solve problems >>>>>>>>>> which >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>> inter-tech handover is try to deal with. >>>>> =20 >>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>> Flow >>>>>>>>> =20 >>>>>>>>> =20 >>>>> mobility also includes the ability to move a flow from one mobility >>>>> =20 >>>>> session to another. Multiple mobility sessions could be established v= ia >>>>> =20 >>>>> a >>>>> =20 >>>>> =20 >>>>>>>>> single interface in which case flow mobility would be achieved >>>>>>>>> =20 >>>>>>>>> =20 >>>>> within >>>>> =20 >>>>> =20 >>>>>>>>> the >>>>>>>>> scope of a single interface. Hence flow mobility and >>>>>>>>> =20 >>>>>>>>> =20 >>>>> inter-technology >>>>> =20 >>>>> =20 >>>>>>>>> handovers are separate features. >>>>>>>>> Frank=3D>IMHO, >>>>>>>>> =20 >>>>>>>>> =20 >>>>> inter-technology is trying to move all the traffic on >>>>> =20 >>>>> =20 >>>>>>>>> one interface to >>>>>>>>> =20 >>>>>>>>> =20 >>>>> another interface. >>>>> =20 >>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>> Right. I guess you answered the >>>>>>>> =20 >>>>>>>> =20 >>>>> question about the difference between >>>>> =20 >>>>> =20 >>>>>>>> flow >>>>>>>> mobility and >>>>>>>> =20 >>>>>>>> =20 >>>>> inter-technology handovers. You could extrapolate and say >>>>> =20 >>>>> =20 >>>>>>>> that >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> =20 >>>>> inter-technology HO is the case where you move all flows from one >>>>> =20 >>>>> interface >>>>> =20 >>>>> =20 >>>>>>>> to another and hence a variant of flow mobility. While that is >>>>>>>> =20 >>>>>>>> =20 >>>>> true, you >>>>> =20 >>>>> =20 >>>>>>>> should also recognize that the granularity of flow mobility is >>>>>>>> =20 >>>>>>>> =20 >>>>> finer and >>>>> =20 >>>>> =20 >>>>>>>> does not have to necessarily be a relocation of a flow between >>>>>>>> =20 >>>>>>>> =20 >>>>> physical >>>>> =20 >>>>> =20 >>>>>>>> interfaces. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>>>> I assume that two >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>> heterogeneous interfaces are >>>>> =20 >>>>> =20 >>>>>>>>>> all active during the handover. It is >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>> easy to move >>>>> =20 >>>>> =20 >>>>>>>>>> a flow(or all flows) from an interface to >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>> another. >>>>> =20 >>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>> Possibly.. But the point is to >>>>>>>>> =20 >>>>>>>>> =20 >>>>> identify what extensions (possibly to the >>>>> =20 >>>>> =20 >>>>>>>>> MN) >>>>>>>>> are needed in order >>>>>>>>> =20 >>>>>>>>> =20 >>>>> to achieve handovers across interfaces. >>>>> =20 >>>>> =20 >>>>>>>>> Frank=3D>If we see inter-tech >>>>>>>>> =20 >>>>>>>>> =20 >>>>> handover as a subset of flow mobility, >>>>> =20 >>>>> =20 >>>>>>>>> there is one problem left, that >>>>>>>>> =20 >>>>>>>>> =20 >>>>> is flow mobility. >>>>> =20 >>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>> See above. Flow mobility is a >>>>>>>> =20 >>>>>>>> =20 >>>>> feature that can work across multiple >>>>> =20 >>>>> =20 >>>>>>>> mobility >>>>>>>> sessions within the >>>>>>>> =20 >>>>>>>> =20 >>>>> scope of a single interface as well. >>>>> =20 >>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>>>> This is >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>> probably the reason why there is no >>>>> =20 >>>>> =20 >>>>>>>>>> inter-tech handover solution >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>> standerdized >>>>> =20 >>>>> =20 >>>>>>>>>> for client MIP. >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>> Client >>>>>>>>> =20 >>>>>>>>> =20 >>>>> MIP inherently supports handovers across multiple interfaces. >>>>> =20 >>>>> Performance improvements to the handovers are accomplished using >>>>> =20 >>>>> solutions >>>>> =20 >>>>> =20 >>>>>>>>> such as FMIP. >>>>>>>>> Frank=3D>Maybe, I am missing something. >>>>>>>>> =20 >>>>>>>>> =20 >>>>> However FMIP is not applicable >>>>> =20 >>>>> =20 >>>>>>>>> to PAR/NAR collocated scenario. For >>>>>>>>> =20 >>>>>>>>> =20 >>>>> example, a mobile node with two >>>>> =20 >>>>> =20 >>>>>>>>> interface connects to the same access >>>>>>>>> =20 >>>>>>>>> =20 >>>>> router (ASN-GW for WiMAX, >>>>> =20 >>>>> =20 >>>>>>>>> PDN-GW for LTE). Does FMIP work when mobile >>>>>>>>> =20 >>>>>>>>> =20 >>>>> node handover from >>>>> =20 >>>>> =20 >>>>>>>>> one technology to another? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>> Not sure I understand the question. In your example above, I belie= ve >>>>>>>> =20 >>>>>>>> =20 >>>>> the >>>>> =20 >>>>> =20 >>>>>>>> MN >>>>>>>> would connect to the ASN-GW via the WiMAX interface and to an >>>>>>>> =20 >>>>>>>> =20 >>>>> S-GW via >>>>> =20 >>>>> =20 >>>>>>>> the >>>>>>>> LTE interface. The P-GW (LMA) may be the same. If the >>>>>>>> =20 >>>>>>>> =20 >>>>> question is, can >>>>> =20 >>>>> =20 >>>>>>>> you >>>>>>>> use FMIP to optimize handovers in such a >>>>>>>> =20 >>>>>>>> =20 >>>>> scenario... Yes. Not FMIP, but >>>>> =20 >>>>> =20 >>>>>>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't >>>>>>>> =20 >>>>>>>> =20 >>>>> think we are looking at >>>>> =20 >>>>> =20 >>>>>>>> optimizing >>>>>>>> handovers in this >>>>>>>> =20 >>>>>>>> =20 >>>>> discussion. >>>>> =20 >>>>> =20 >>>>>>>> As per the current PMIP6 specification wherein no changes to >>>>>>>> =20 >>>>>>>> =20 >>>>> the host are >>>>> =20 >>>>> =20 >>>>>>>> required, it is not possible to do an inter-technology >>>>>>>> =20 >>>>>>>> =20 >>>>> handover. This is >>>>> =20 >>>>> =20 >>>>>>>> a >>>>>>>> limitation which implies that PMIP6 provides >>>>>>>> =20 >>>>>>>> =20 >>>>> host mobility to an MN >>>>> =20 >>>>> =20 >>>>>>>> within >>>>>>>> the scope of a single access >>>>>>>> =20 >>>>>>>> =20 >>>>> technology. Host based mobile IP does not >>>>> =20 >>>>> =20 >>>>>>>> have >>>>>>>> this >>>>>>>> =20 >>>>>>>> =20 >>>>> problem. >>>>> =20 >>>>> =20 >>>>>>>> -Raj >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>>> -Raj >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>>> BR >>>>>>>>>> Frank >>>>>>>>>>=20 >>>>>>>>>> ----- Original Message ----- >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>> From: "marcelo bagnulo braun" >>>>> =20 >>>>> =20 >>>>>>>>>> To: >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>> ; "mext" ; >>>>> =20 >>>>> =20 >>>>>>>>>> Cc: >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>> ; "Ralph Droms" >>>>> =20 >>>>> =20 >>>>>>>>>> Sent: >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>> Sunday, June 28, 2009 1:16 PM >>>>> =20 >>>>> =20 >>>>>>>>>> Subject: [netlmm] NEXTEXT2: first draft >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>> of the bof description >>>>> =20 >>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>> Hi, >>>>> =20 >>>>> =20 >>>>>>>>>>> This is a first draft of the BOF description for your >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> consideration. >>>>> =20 >>>>> =20 >>>>>>>>>>> It >>>>>>>>>>> is >>>>>>>>>>> still very open so, feel free to >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> comment on whether the proposed >>>>> =20 >>>>> =20 >>>>>>>>>>> approach >>>>>>>>>>> seems appropriate or >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> not. >>>>> =20 >>>>> =20 >>>>>>>>>>> NETEXT2 BOF description >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> ----------------------- >>>>> =20 >>>>> =20 >>>>>>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> a network based mobility >>>>> =20 >>>>> =20 >>>>>>>>>>> protocol built on Mobile IPv6 [RFC3775]. >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> PMIP6 provides mobility to >>>>> =20 >>>>> =20 >>>>>>>>>>> IP hosts without requiring any protocol >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> enhancements or additional >>>>> =20 >>>>> =20 >>>>>>>>>>> capabilities on the host. >>>>>>>>>>> Current >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> PMIP6 specification fully defines how to provide mobility >>>>> =20 >>>>> =20 >>>>>>>>>>> support for >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> mobile nodes with a single interface roaming in a PMIP6 >>>>> =20 >>>>> =20 >>>>>>>>>>> domain. The >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> goal of this BOF is gain understanding of how to support >>>>> =20 >>>>> =20 >>>>>>>>>>> nodes with >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> multiple interfaces (of possible different technologies) in >>>>> =20 >>>>> =20 >>>>>>>>>>> a >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> PMIP6 network. >>>>> =20 >>>>> =20 >>>>>>>>>>> In particular, this BOF assumes the following >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> scenario: >>>>> =20 >>>>> =20 >>>>>>>>>>> We have a single PMIP6 domain that has deployed >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> multiple >>>>> =20 >>>>> =20 >>>>>>>>>>> access technologies and needs to support nodes that >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> have >>>>> =20 >>>>> =20 >>>>>>>>>>> multiple interfaces, possibly of different >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> technologies. >>>>> =20 >>>>> =20 >>>>>>>>>>> In particular, the following capabilities are >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> needed: >>>>> =20 >>>>> =20 >>>>>>>>>>> - Inter-technology handover support. The MN has >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> initiated a >>>>> =20 >>>>> =20 >>>>>>>>>>> communication over one interface and it needs to be able >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> to move >>>>> =20 >>>>> =20 >>>>>>>>>>> the established connection to a different interface of >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> a possibly different technology. The reason for moving >>>>> =20 >>>>> =20 >>>>>>>>>>> the >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> communication to another interface is because of the MNs >>>>> =20 >>>>> =20 >>>>>>>>>>> mobility and >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> attaching via a different interface. Basically >>>>> =20 >>>>> =20 >>>>>>>>>>> the ability to perform >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> handovers that span different access >>>>> =20 >>>>> =20 >>>>>>>>>>> technologies. >>>>>>>>>>>=20 >>>>>>>>>>> - >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> Multihoming support. The MN with multiple interfaces of possibly >>>>> =20 >>>>> different technologies should be able to use them simultaneously to >>>>> =20 >>>>> exchange data and manage the mobility of communications >>>>> =20 >>>>> =20 >>>>>>>>>>> established >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> through the different interfaces. >>>>> =20 >>>>> =20 >>>>>>>>>>> - Flow mobility. A MN with >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> multiple interfaces of possibly >>>>> =20 >>>>> =20 >>>>>>>>>>> different technologies must be able to >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> move a flow from >>>>> =20 >>>>> =20 >>>>>>>>>>> one interface to another. Moreover, the MN should be >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> able >>>>> =20 >>>>> =20 >>>>>>>>>>> to inform the network through which interface it wishes >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> to receive different types of flows. >>>>> =20 >>>>> =20 >>>>>>>>>>> In order to provide the >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> support for these capabilities, different >>>>> =20 >>>>> =20 >>>>>>>>>>> approaches can be >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> envisioned, namely: >>>>> =20 >>>>> =20 >>>>>>>>>>> - L2 only approaches. In this type of approaches, >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> the mechanisms >>>>> =20 >>>>> =20 >>>>>>>>>>> to provide the required capabilities are fully L2 >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> mechanisms and >>>>> =20 >>>>> =20 >>>>>>>>>>> no modification of the IP layer is needed. >>>>>>>>>>> - L3 >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> only approaches. In this type of approaches, the mechanism to >>>>> =20 >>>>> =20 >>>>>>>>>>> provide >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> to required capabilities are located in the IP layer >>>>> =20 >>>>> =20 >>>>>>>>>>> - Hybrid L2/L3 >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> approaches. In this case, some mechanisms are >>>>> =20 >>>>> =20 >>>>>>>>>>> located in L2 and other >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> mechanisms are located in L3. >>>>> =20 >>>>> =20 >>>>>>>>>>> Now, the different possible approaches >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> vary greatly in their nature >>>>> =20 >>>>> =20 >>>>>>>>>>> and resulting capabilities. To >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> understanding the benefits and >>>>> =20 >>>>> =20 >>>>>>>>>>> suitability of these alternatives, the >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> requirements have to be >>>>> =20 >>>>> =20 >>>>>>>>>>> properly defined and >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> understood. >>>>> =20 >>>>> =20 >>>>>>>>>>> The main goal of the BOF is understanding the need >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> for work in the >>>>> =20 >>>>> =20 >>>>>>>>>>> IETF in this area. In order to do so, during the BOF, >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> we will attempt >>>>> =20 >>>>> =20 >>>>>>>>>>> to: >>>>>>>>>>>=20 >>>>>>>>>>> 1) Understand the applicable >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> scenarios, and the problem statement >>>>> =20 >>>>> =20 >>>>>>>>>>> related >>>>>>>>>>> to >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> those >>>>> =20 >>>>> =20 >>>>>>>>>>> 2) Understand the restrictions and requirement imposed to >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> solutions to >>>>> =20 >>>>> =20 >>>>>>>>>>> address the problem statement and scenarios >>>>>>>>>>> 3) >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> Get an overview of the proposed solutions >>>>> =20 >>>>> =20 >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> _______________________________________________ >>>>> =20 >>>>> =20 >>>>>>>>>>> netlmm mailing >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> list >>>>> =20 >>>>> =20 >>>>>>>>>>> netlmm@ietf.org >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>> https://www.ietf.org/mailman/listinfo/netlmm >>>>> =20 >>>>> =20 >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>>>>>> _______________________________________________ >>>>>>>>> netext mailing >>>>>>>>> =20 >>>>>>>>> =20 >>>>> list >>>>> =20 >>>>> =20 >>>>>>>>> netext@ietf.org >>>>>>>>>=20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>> https://www.ietf.org/mailman/listinfo/netext >>>>> =20 >>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>> _______________________________________________ >>>>> =20 >>>>> =20 >>>>>>> MEXT mailing list >>>>>>>=20 >>>>>>> =20 >>>>>>> =20 >>>>> MEXT@ietf.org >>>>> =20 >>>>> =20 >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> =20 >>>>>>> =20 >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>> MEXT@ietf.org >>>>> =20 >>>>> =20 >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>> _______________________________________________ >>>>> netlmm mailing list >>>>>=20 >>>>> netlmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netlmm >>>>>=20 >>>>>=20 >>>>> =20 >>>>> =20 >>>> _______________________________________________ >>>> netlmm mailing >>>> =20 >>>> =20 >>>>> list >>>>> =20 >>>>> =20 >>>> netlmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netlmm >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> =20 >>>> =20 >>=20 >>=20 >>=20 >> =20 >=20 From Basavaraj.Patil@nokia.com Tue Jun 30 09:21:32 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B0CE3A6767; Tue, 30 Jun 2009 09:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.202 X-Spam-Level: X-Spam-Status: No, score=-6.202 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] 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 GTMBOlUdnqv4; Tue, 30 Jun 2009 09:21:30 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 1B2FE3A6A3E; Tue, 30 Jun 2009 09:21:28 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5UGKroI018833; Tue, 30 Jun 2009 19:20:59 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Jun 2009 19:20:56 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Jun 2009 19:20:56 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Jun 2009 19:20:51 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 30 Jun 2009 18:20:50 +0200 From: To: , Date: Tue, 30 Jun 2009 18:20:57 +0200 Thread-Topic: [MEXT] [netext] [netlmm] NEXTEXT2: first draft of the bof description Thread-Index: Acn5cH16KsIi/mK8Sy2cO1N/w5sfaQALkIIh Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jun 2009 16:20:51.0451 (UTC) FILETIME=[BC3504B0:01C9F99E] X-Nokia-AV: Clean Cc: netlmm@ietf.org, mext@ietf.org Subject: Re: [MEXT] [netext] [netlmm] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 16:21:32 -0000 Hi George, On 6/30/09 5:49 AM, "ext George Tsirtsis" wrote: > Hi Charlie/Raj, et.al., > > In intra-technology handoffs, Make Before Break (MBB) is the ability > of the given technology to acquire a connection to the new BS/sector > while maintaining the connection to the existing BS/sector. > > CDMA sited as an example of technology capable of MBB, is maybe not > the best one since the MBB functionality of CDMA is really at the PHY > layer i.e., the MN maintains a single link to a BS-Controller type box > over one or more PHY-layer connections to BSs. So this is PHY layer > MBB. > > OFDMA on the other hand, at least as implemented in Flash-OFDM (a less > known technology), is capable of implementing link layer MBB where an > MN can create two independent link layer connections to two different > BSs (in Flash-OFDM playing the role of MIPv4 FAs), but that seems to > be an unusual case so far. > > Most technologies, seem to hide intra-technology handoff from the IP > layer, and instead present a stable interface that to the IP layer it > does not appear to be moving. So often, intra-technology handoffs of > that kind (whether it is MBB or BBM) are transparent to the IETF. Agree. No doubt that the intricacies of the underlying technologies are not something that we should be worrying about in the IETF or building solution= s for specific cases. > > Inter-technology handoffs are a bit different. In some cases, such > handoffs are still hidden from the IP layer, e.g., handoffs between > 3GPP-specific technologies tends to be handled at lower layers. > > In other cases, however, such handoffs are visible to IP. This happens > when each of the technology-specific interfaces present a different > interface to the IP layer. In this case the interfaces tend to come up > and down independently from each other (e.g., WLAN and 3G), but that > is often also limited by the capabilities of the device e.g., a lot of > devices can only transmit/receive over one radio at the time (strictly > an implementation issue). Wifi/3G at least the way they are implemented give the illusion of both radios being capable of Tx/Rx simultaneously... At least from the IP layer perspective. But as you said, implementations vary and form factors of devices such as handhelds vs notebook computers also make a difference. > > People also often forget inter-domain handoffs. These, whether intra- > or inter-technology, can also in some cases be visible to the IP > layer. Sure. > > The bottom line is that at the *network layer* we should not be making > too many assumptions about the capabilities of the lower layers. We > should instead define generic mechanisms that can be widely applied, > so for example, MIP+MCoA+FlowBindings, says nothing about MBB/BBM (and > it says even less about inter/intra-technology/domain) and it works > with all of the above. When I say it works, I mean the protocol is > self-consistent in all of these cases, but obviously when you can only > do BBM handoffs, MCoA and FlowBindings are not as useful; which is > fine. I agree about the fundamental view that at the network layer, we should be agnostic to the lower layer capabilities and not design a protocol that works only for specific L1/2s. However as you are well aware the network layer does work much more optimally if it is aware of the lower layer capabilities and such aspects have crept into the protocol specifications i= n the IETF. I agree that in certain cases BBM is just fine and there is reall= y not a need to be able to accomplish MBB only in all cases. > > With PMIP things are not so clear....it is not even clear we are > talking about the *network layer*... and thus it is not so clear how > "generic" solutions can be. I guess you have a different view about PMIP. But the goal is to develop solutions that are "generic". I believe your point has been that developing such a generic solution will be equivalent to basically reinventing host based mobility protocol capability between the MN and MAG. I guess if the conclusion boils down to such, then we can simply state the obvious. But at this time I believe it is not a given and hence this exercise. > > The challenge for the BOF is to throw some light on how PMIP can be > compatible with this extended functionality, what type of additional > signalling is needed, and at which layer they intend to implement such > signalling. Let's see. Yes.. I think the BoF is intended to clarify these questions. -Raj > > George > > On Tue, Jun 30, 2009 at 1:43 AM, Charles E. > Perkins wrote: >> >> Hello Basavaraj, >> >> Isn't make-before-break a function performed >> at the link layer? >> >> It certainly isn't PHY, and I wouldn't think it >> qualifies as MAC (i.e., it doesn't control the >> device's access to the medium). >> >> Regards, >> Charlie P. >> >> PS. Which is the proper mailing list for this discussion? >> >> Basavaraj.Patil@nokia.com wrote: >>> >>> Hi Frank, >>> >>> Make-before-break is inherently supported in certain technologies such = as >>> CDMA/WCDMA (which has soft HO features built in). The same is not possi= ble >>> for example in TDMA (GSM) or OFDMA (802.16e and WiFi). 802.16e does hav= e a >>> contorted mechansim for achieving the same but that's besides the point= . >>> So IMO it is a capability of the Phy/Mac. >>> However it is possible to emulate soft-handovers and achieve >>> make-before-break in certain cases. For example it is possible to be >>> simultaneously connected to HSPA and WiFi and accomplish a >>> make-before-break >>> HO. I guess the definition of the term depends on an access tchnology o= r >>> the >>> combination of access technologies in the context of a use-case. >>> >>> -Raj >>> >>> >>> On 6/29/09 4:36 PM, "ext Frank Xia" wrote: >>> >>> >>>> >>>> Hi Raj >>>> >>>> IMHO Make-before-break is not a link-layer technology. >>>> , but a concept (or a strategy). Related to the topic we >>>> are discussing, making target interface ready before moving >>>> traffic to it is kind of make-before-break. >>>> >>>> BR >>>> Frank >>>> >>>> ----- Original Message ----- >>>> From: >>>> To: ; ; ; >>>> ; >>>> Cc: ; >>>> Sent: Monday, June 29, 2009 3:43 PM >>>> Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof >>>> description >>>> >>>> >>>> >>>> Hi Frank, >>>> >>>> Comments inline: >>>> >>>> >>>> On 6/29/09 2:57 PM, "ext Frank Xia" wrote: >>>> >>>> >>>>> >>>>> Hi Raj >>>>> >>>>> My main point is make-before-break strategy >>>>> is the best way to solve multi-radio handover. >>>>> >>>> >>>> The IETF cannot do anything about whether an MN has the ability to >>>> accomplish make-before-break connectivity. It depends on the link-laye= r >>>> technology, spectrum that they operate in, etc. So this approach is a >>>> non-starter. The IETF solution has to be agnostic to underlying access >>>> technologies. >>>> >>>> >>>>> >>>>> Please see my inline response. >>>>> >>>>> BR >>>>> ----- Original Message ----- >>>>> From: >>>>> To: ; ; = ; >>>>> ; >>>>> Cc: ; >>>>> Sent: Monday, June 29, 2009 11:50 AM >>>>> Subject: Re: [netlmm] NEXTEXT2: first draft of the bof description >>>>> >>>>> >>>>> >>>>> Frank, >>>>> >>>>> >>>>> On 6/29/09 11:16 AM, "ext Frank Xia" wrote: >>>>> >>>>> >>>>>> >>>>>> Hi Guys >>>>>> >>>>>> I have comments on inter-technology handover. >>>>>> >>>>>> IMHO, flow mobility could solve problems >>>>>> which inter-tech handover is try to deal with. >>>>>> >>>>> >>>>> Flow mobility also includes the ability to move a flow from one mobil= ity >>>>> session to another. Multiple mobility sessions could be established v= ia >>>>> a >>>>> single interface in which case flow mobility would be achieved within >>>>> the >>>>> scope of a single interface. Hence flow mobility and inter-technology >>>>> handovers are separate features. >>>>> Frank=3D>IMHO, inter-technology is trying to move all the traffic on >>>>> one interface to another interface. >>>>> >>>> >>>> Right. I guess you answered the question about the difference between >>>> flow >>>> mobility and inter-technology handovers. You could extrapolate and say >>>> that >>>> inter-technology HO is the case where you move all flows from one >>>> interface >>>> to another and hence a variant of flow mobility. While that is true, y= ou >>>> should also recognize that the granularity of flow mobility is finer a= nd >>>> does not have to necessarily be a relocation of a flow between physica= l >>>> interfaces. >>>> >>>>>> >>>>>> I assume that two heterogeneous interfaces are >>>>>> all active during the handover. It is easy to move >>>>>> a flow(or all flows) from an interface to another. >>>>>> >>>>> >>>>> Possibly.. But the point is to identify what extensions (possibly to = the >>>>> MN) >>>>> are needed in order to achieve handovers across interfaces. >>>>> Frank=3D>If we see inter-tech handover as a subset of flow mobility, >>>>> there is one problem left, that is flow mobility. >>>>> >>>> >>>> See above. Flow mobility is a feature that can work across multiple >>>> mobility >>>> sessions within the scope of a single interface as well. >>>> >>>> >>>>>> >>>>>> This is probably the reason why there is no >>>>>> inter-tech handover solution standerdized >>>>>> for client MIP. >>>>>> >>>>> >>>>> Client MIP inherently supports handovers across multiple interfaces. >>>>> Performance improvements to the handovers are accomplished using >>>>> solutions >>>>> such as FMIP. >>>>> Frank=3D>Maybe, I am missing something. However FMIP is not applica= ble >>>>> to PAR/NAR collocated scenario. For example, a mobile node with two >>>>> interface connects to the same access router (ASN-GW for WiMAX, >>>>> PDN-GW for LTE). Does FMIP work when mobile node handover from >>>>> one technology to another? >>>>> >>>> >>>> Not sure I understand the question. In your example above, I believe t= he >>>> MN >>>> would connect to the ASN-GW via the WiMAX interface and to an S-GW via >>>> the >>>> LTE interface. The P-GW (LMA) may be the same. If the question is, can >>>> you >>>> use FMIP to optimize handovers in such a scenario... Yes. Not FMIP, bu= t >>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't think we are looking at >>>> optimizing >>>> handovers in this discussion. >>>> As per the current PMIP6 specification wherein no changes to the host = are >>>> required, it is not possible to do an inter-technology handover. This = is >>>> a >>>> limitation which implies that PMIP6 provides host mobility to an MN >>>> within >>>> the scope of a single access technology. Host based mobile IP does not >>>> have >>>> this problem. >>>> >>>> -Raj >>>> >>>> >>>>> >>>>> -Raj >>>>> >>>>> >>>>>> >>>>>> BR >>>>>> Frank >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "marcelo bagnulo braun" >>>>>> To: ; "mext" ; >>>>>> Cc: ; "Ralph Droms" >>>>>> Sent: Sunday, June 28, 2009 1:16 PM >>>>>> Subject: [netlmm] NEXTEXT2: first draft of the bof description >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> This is a first draft of the BOF description for your consideration= . >>>>>>> It >>>>>>> is >>>>>>> still very open so, feel free to comment on whether the proposed >>>>>>> approach >>>>>>> seems appropriate or not. >>>>>>> >>>>>>> NETEXT2 BOF description >>>>>>> ----------------------- >>>>>>> >>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility >>>>>>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to >>>>>>> IP hosts without requiring any protocol enhancements or additional >>>>>>> capabilities on the host. >>>>>>> Current PMIP6 specification fully defines how to provide mobility >>>>>>> support for mobile nodes with a single interface roaming in a PMIP6 >>>>>>> domain. The goal of this BOF is gain understanding of how to suppor= t >>>>>>> nodes with multiple interfaces (of possible different technologies)= in >>>>>>> a >>>>>>> PMIP6 network. >>>>>>> >>>>>>> In particular, this BOF assumes the following scenario: >>>>>>> We have a single PMIP6 domain that has deployed multiple >>>>>>> access technologies and needs to support nodes that have >>>>>>> multiple interfaces, possibly of different technologies. >>>>>>> >>>>>>> In particular, the following capabilities are needed: >>>>>>> >>>>>>> - Inter-technology handover support. The MN has initiated a >>>>>>> communication over one interface and it needs to be able to move >>>>>>> the established connection to a different interface of >>>>>>> a possibly different technology. The reason for moving >>>>>>> the communication to another interface is because of the MNs >>>>>>> mobility and attaching via a different interface. Basically >>>>>>> the ability to perform handovers that span different access >>>>>>> technologies. >>>>>>> >>>>>>> - Multihoming support. The MN with multiple interfaces of possibly >>>>>>> different technologies should be able to use them simultaneously to >>>>>>> exchange data and manage the mobility of communications >>>>>>> established through the different interfaces. >>>>>>> >>>>>>> - Flow mobility. A MN with multiple interfaces of possibly >>>>>>> different technologies must be able to move a flow from >>>>>>> one interface to another. Moreover, the MN should be able >>>>>>> to inform the network through which interface it wishes >>>>>>> to receive different types of flows. >>>>>>> >>>>>>> In order to provide the support for these capabilities, different >>>>>>> approaches can be envisioned, namely: >>>>>>> - L2 only approaches. In this type of approaches, the mechanisms >>>>>>> to provide the required capabilities are fully L2 mechanisms and >>>>>>> no modification of the IP layer is needed. >>>>>>> - L3 only approaches. In this type of approaches, the mechanism to >>>>>>> provide to required capabilities are located in the IP layer >>>>>>> - Hybrid L2/L3 approaches. In this case, some mechanisms are >>>>>>> located in L2 and other mechanisms are located in L3. >>>>>>> Now, the different possible approaches vary greatly in their nature >>>>>>> and resulting capabilities. To understanding the benefits and >>>>>>> suitability of these alternatives, the requirements have to be >>>>>>> properly defined and understood. >>>>>>> >>>>>>> The main goal of the BOF is understanding the need for work in the >>>>>>> IETF in this area. In order to do so, during the BOF, we will attem= pt >>>>>>> to: >>>>>>> >>>>>>> 1) Understand the applicable scenarios, and the problem statement >>>>>>> related >>>>>>> to >>>>>>> those >>>>>>> 2) Understand the restrictions and requirement imposed to solutions= to >>>>>>> address the problem statement and scenarios >>>>>>> 3) Get an overview of the proposed solutions >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> netlmm mailing list >>>>>>> netlmm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netlmm >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> netext mailing list >>>>> netext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netext >>>>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> From Telemaco.Melia@alcatel-lucent.com Tue Jun 30 09:22:26 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94D183A69D5; Tue, 30 Jun 2009 09:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] 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 mdNzqKufU0WZ; Tue, 30 Jun 2009 09:22:25 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id CE0CF3A6767; Tue, 30 Jun 2009 09:22:24 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n5UGLZYG023645; Tue, 30 Jun 2009 18:21:35 +0200 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Jun 2009 18:21:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Jun 2009 18:21:34 +0200 Message-ID: <853DD750D9C3724FBF2DF7164FCF641C032B79C2@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: <4A4A3135.7060105@nw.neclab.eu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] [MEXT] NEXTEXT2: first draft of the bof description Thread-Index: Acn5mMVeUUTcpRDgQgW6OsAnumzt7AABeTKw References: <4A47B36B.9030702@it.uc3m.es> <000e01c9f8d4$ff2bde30$3e0c7c0a@china.huawei.com> <001401c9f8dd$d6c16830$3e0c7c0a@china.huawei.com> <853DD750D9C3724FBF2DF7164FCF641C032776AE@FRVELSMBS14.ad2.ad.alcatel.com> <004b01c9f8f7$56779d60$3e0c7c0a@china.huawei.com> <4A4A3135.7060105@nw.neclab.eu> From: "MELIA TELEMACO" To: "Marco Liebsch" , "Frank Xia" X-OriginalArrivalTime: 30 Jun 2009 16:21:35.0231 (UTC) FILETIME=[D64D50F0:01C9F99E] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: mext , netlmm@ietf.org, netext-chairs@tools.ietf.org, netext@ietf.org Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 16:22:26 -0000 Hello, Please see below. > > This is a rare case. If "inter-technology handover" > focuses on dealing with this scenario, I am fine. Still inter-tech handover is different from flow mobility. Also=20 complexity-wise. For inter-technology handover the mobile may only provide hints about=20 the nature of the handover (inter-tech HO etc), maybe about handover target or source=20 to the network. If you want flow mobility, you need to handle flow descriptions and=20 signal appropriate filters, hence much more to be done by the mobile and by the network. Not sure the PMIPv6 protocol should handle flow filters.. If you move all flows during a handover, we're back at inter-tech=20 handover, say we move the complete mobility session with the intention to shut down the=20 previous mobility session (and with mobility session I mean the MN's binding=20 between the HNP and the pMAG at the LMA). Moving the associated flows is implicit. Hence, requirement on the mobile is very different for flow mobility and = inter-tech handover (shouldn't we say dual radio handover here?) TELE: pretty much agree Telemaco marco > > BR > Frank > > ----- Original Message ----- From: "MELIA TELEMACO"=20 > > To: "Frank Xia" ; "George Tsirtsis"=20 > > Cc: ; ;=20 > ; "mext" > Sent: Monday, June 29, 2009 1:03 PM > Subject: RE: [netlmm] [MEXT] NEXTEXT2: first draft of the bof = description > > > Frank, > > I think you should not mix flow mobility and inter-tech handover. A MN = > might or might now use multiple connections at the same time... > > telemaco > > -----Message d'origine----- > De : netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] De la=20 > part de Frank Xia > Envoy=E9 : lundi 29 juin 2009 19:20 > =C0 : George Tsirtsis > Cc : netext@ietf.org; netlmm@ietf.org; netext-chairs@tools.ietf.org; = mext > Objet : Re: [netlmm] [MEXT] NEXTEXT2: first draft of the bof = description > > Hi Gorge > > It seems that I did not make me clear. > > 1)Single radio handover. > MN should disconnect from one BS , and connect > to a second BS. MN can't connect to the two BS > at the same time. Handover solutions (FMIP/PMIP) > are needed. > > 2)Dual radio handover > MN connects to the two BS' at the same time. > Flow mobility is sufficient when move a flow( or all > flows) from one interface to another. > > BR > Frank > > ----- Original Message ----- From: "George Tsirtsis"=20 > > To: "Frank Xia" > Cc: "marcelo bagnulo braun" ; ;=20 > "mext" > ; ; > Sent: Monday, June 29, 2009 11:48 AM > Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof = description > > > Frank, your comment below is strange to say the least. > > MIP handoffs can be between interfaces of the same or different > technologies. Since client MIP works at the IP layer (above the Link > Layer of any specific technology) there is nothing that client MIP > (and any of its features) need to specifically define for > inter-technology handoffs. > > >Did you so far think that this means that client MIP only works > intra-technology?< > > For PMIP, this is an issue because currently there is no defined > protocol (on any layer) between MN and MAG...which is one of the > issues to be discussed in netext2 bof. > > George > > On Mon, Jun 29, 2009 at 5:16 PM, Frank Xia = wrote: >> Hi Guys >> >> I have comments on inter-technology handover. >> >> IMHO, flow mobility could solve problems >> which inter-tech handover is try to deal with. >> I assume that two heterogeneous interfaces are >> all active during the handover. It is easy to move >> a flow(or all flows) from an interface to another. >> >> This is probably the reason why there is no >> inter-tech handover solution standerdized >> for client MIP. >> >> BR >> Frank >> >> ----- Original Message ----- From: "marcelo bagnulo braun" >> >> To: ; "mext" ; >> Cc: ; "Ralph Droms" >> Sent: Sunday, June 28, 2009 1:16 PM >> Subject: [netlmm] NEXTEXT2: first draft of the bof description >> >> >>> Hi, >>> >>> This is a first draft of the BOF description for your consideration. = It >>> is >>> still very open so, feel free to comment on whether the proposed=20 >>> approach >>> seems appropriate or not. >>> >>> NETEXT2 BOF description >>> ----------------------- >>> >>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility >>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to >>> IP hosts without requiring any protocol enhancements or additional >>> capabilities on the host. >>> Current PMIP6 specification fully defines how to provide mobility >>> support for mobile nodes with a single interface roaming in a PMIP6 >>> domain. The goal of this BOF is gain understanding of how to support >>> nodes with multiple interfaces (of possible different technologies)=20 >>> in a >>> PMIP6 network. >>> >>> In particular, this BOF assumes the following scenario: >>> We have a single PMIP6 domain that has deployed multiple >>> access technologies and needs to support nodes that have >>> multiple interfaces, possibly of different technologies. >>> >>> In particular, the following capabilities are needed: >>> >>> - Inter-technology handover support. The MN has initiated a >>> communication over one interface and it needs to be able to move >>> the established connection to a different interface of >>> a possibly different technology. The reason for moving >>> the communication to another interface is because of the MNs >>> mobility and attaching via a different interface. Basically >>> the ability to perform handovers that span different access >>> technologies. >>> >>> - Multihoming support. The MN with multiple interfaces of possibly >>> different technologies should be able to use them simultaneously to >>> exchange data and manage the mobility of communications >>> established through the different interfaces. >>> >>> - Flow mobility. A MN with multiple interfaces of possibly >>> different technologies must be able to move a flow from >>> one interface to another. Moreover, the MN should be able >>> to inform the network through which interface it wishes >>> to receive different types of flows. >>> >>> In order to provide the support for these capabilities, different >>> approaches can be envisioned, namely: >>> - L2 only approaches. In this type of approaches, the mechanisms >>> to provide the required capabilities are fully L2 mechanisms and >>> no modification of the IP layer is needed. >>> - L3 only approaches. In this type of approaches, the mechanism to >>> provide to required capabilities are located in the IP layer >>> - Hybrid L2/L3 approaches. In this case, some mechanisms are >>> located in L2 and other mechanisms are located in L3. >>> Now, the different possible approaches vary greatly in their nature >>> and resulting capabilities. To understanding the benefits and >>> suitability of these alternatives, the requirements have to be >>> properly defined and understood. >>> >>> The main goal of the BOF is understanding the need for work in the >>> IETF in this area. In order to do so, during the BOF, we will=20 >>> attempt to: >>> >>> 1) Understand the applicable scenarios, and the problem statement=20 >>> related >>> to >>> those >>> 2) Understand the restrictions and requirement imposed to solutions = to >>> address the problem statement and scenarios >>> 3) Get an overview of the proposed solutions >>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/netlmm >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm From marcelo@it.uc3m.es Tue Jun 30 09:22:57 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18A913A6C7F; Tue, 30 Jun 2009 09:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] 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 yr9qzkB1XIon; Tue, 30 Jun 2009 09:22:54 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 1B24D3A6C0B; Tue, 30 Jun 2009 09:22:54 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-138.dynamic.orange.es [85.53.138.110]) by smtp01.uc3m.es (Postfix) with ESMTP id B5963BA662E; Tue, 30 Jun 2009 17:28:40 +0200 (CEST) Message-ID: <4A4A2F28.3030601@it.uc3m.es> Date: Tue, 30 Jun 2009 17:28:40 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16736.000 Cc: mext , "netlmm@ietf.org" , Basavaraj.Patil@nokia.com Subject: Re: [MEXT] [netlmm] [netext] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 16:22:57 -0000 Hesham Soliman escribió: > >>> => I think the important question to ask is why this is an issue in the >>> first place? If you have a solution for the superset (all link layers) >>> >> you are assuming and answer here, i.e. that the answer is that the >> requirement is a subset, which i don't know if it is the case >> >> >>> and >>> there is a question about whether you need a solution for a subset, then the >>> question we should ask is "why?". This has to be part of the discussion. "we >>> want ....*because*..." >>> >>> >>> >> sure, "why?" is a valid question, but before asking ourselves "why?", we >> need to answer "what?" >> >> So, let's first provide an detailed answer of what is being required to >> support and and that point we will be in good shape to ask "why?" >> i don't think you can ask "why? until a proper answer has been provide >> to "what?" >> >> agree? >> > > => Ok, you're right about my assumption about the answer but it's not coming > from vaccuum :), it's not the first time this is discussed. But ok, I'm > happy to go through this exercise from the beginning. Let's ask "what" and > regardless of the answer ask "why" as well. Because requirements always need > to be justified. > > agree > Hesham > > >> Regards, marcelo >> >> >>> Hesham >>> >>> >>> >>>> Regards, marcelo >>>> >>>> >>>> Hesham Soliman escribió: >>>> >>>> >>>>> A quick comment. >>>>> I don't see any reason for an IETF WG to look for a solution that works for >>>>> a limited set of technologies and try to solve that on layer 2. This is >>>>> clearly not our job. Similarly, there is little gain in solving this for a >>>>> limited set of technologies on L3 given that we already have a layer 2 >>>>> agnostic solution. Why would we want to develop another one for a limited >>>>> set of link layers? >>>>> >>>>> Hesham >>>>> >>>>> >>>>> On 30/06/09 10:39 PM, "marcelo bagnulo braun" wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> George, >>>>>> >>>>>> >>>>>> >>>>> great summary >>>>> >>>>> just one comment below... >>>>> >>>>> >>>>> George Tsirtsis >>>>> >>>>> >>>>> >>>>>> escribió: >>>>>> With PMIP things are not so clear....it is not even clear we are >>>>>> >>>>>> talking about the *network layer*... and thus it is not so clear how >>>>>> >>>>>> "generic" solutions can be. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> right, so one relevant question is how >>>>> >>>>> >>>>> >>>>>> generic we want this to be. >>>>>> >>>>>> >>>>>> >>>>> For instance, it may be also sufficient to support >>>>> >>>>> >>>>> >>>>>> inter technology >>>>>> >>>>>> >>>>>> >>>>> handovers for a subset of L2 technologies that can support >>>>> >>>>> >>>>> >>>>>> it at the L2 >>>>>> >>>>>> >>>>>> >>>>> as you stated. >>>>> So, one thing that we need to define is whether >>>>> >>>>> >>>>> >>>>>> we are looking for a >>>>>> >>>>>> >>>>>> >>>>> solution that supports inter technology handover with >>>>> >>>>> >>>>> >>>>>> any two L2 >>>>>> >>>>>> >>>>>> >>>>> combiantios or are we looking for a solution that supports inter >>>>> >>>>> technology handovers for a limited set of technologies? >>>>> I think this is a key >>>>> >>>>> >>>>> >>>>>> requirements that we need to be explicit about. >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>>> The challenge for the BOF >>>>>> is to throw some light on how PMIP can be >>>>>> compatible with this extended >>>>>> functionality, what type of additional >>>>>> signalling is needed, and at which >>>>>> layer they intend to implement such >>>>>> signalling. Let's see. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> while i >>>>> >>>>> >>>>> >>>>>> agree with that, i think a first step that this bof needs to >>>>>> >>>>>> >>>>>> >>>>> throw some light >>>>> >>>>> >>>>> >>>>>> on is what are the functional requirements for the >>>>>> >>>>>> >>>>>> >>>>> support of the required >>>>> >>>>> >>>>> >>>>>> features. I think the previous is a good example >>>>>> >>>>>> >>>>>> >>>>> of one requirement that we >>>>> >>>>> >>>>> >>>>>> need to flesh out. There are many others. >>>>>> >>>>>> >>>>>> >>>>> Regards, marcelo >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> George >>>>>> >>>>>> On >>>>>> Tue, Jun 30, 2009 at 1:43 AM, Charles E. >>>>>> >>>>>> Perkins wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hello Basavaraj, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Isn't make-before-break a function performed >>>>>> >>>>>> >>>>>> >>>>>>> at the link layer? >>>>>>> >>>>>>> It >>>>>>> >>>>>>> >>>>>>> >>>>>> certainly isn't PHY, and I wouldn't think it >>>>>> >>>>>> >>>>>> >>>>>>> qualifies as MAC (i.e., it >>>>>>> >>>>>>> >>>>>>> >>>>>> doesn't control the >>>>>> >>>>>> >>>>>> >>>>>>> device's access to the medium). >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Charlie P. >>>>>> >>>>>> >>>>>> >>>>>>> PS. Which is the proper mailing list for this >>>>>>> >>>>>>> >>>>>>> >>>>>> discussion? >>>>>> >>>>>> >>>>>> >>>>>>> Basavaraj.Patil@nokia.com wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> Frank, >>>>>> >>>>>> >>>>>> >>>>>>>> Make-before-break is inherently supported in certain >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> technologies such as >>>>>> >>>>>> >>>>>> >>>>>>>> CDMA/WCDMA (which has soft HO features built in). The >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> same is not possible >>>>>> >>>>>> >>>>>> >>>>>>>> for example in TDMA (GSM) or OFDMA (802.16e and >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> WiFi). 802.16e does have a >>>>>> >>>>>> >>>>>> >>>>>>>> contorted mechansim for achieving the same but >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> that's besides the point. >>>>>> >>>>>> >>>>>> >>>>>>>> So IMO it is a capability of the Phy/Mac. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> However it is possible to emulate soft-handovers and achieve >>>>>> >>>>>> make-before-break in certain cases. For example it is possible to be >>>>>> >>>>>> simultaneously connected to HSPA and WiFi and accomplish a >>>>>> >>>>>> make-before-break >>>>>> >>>>>> >>>>>> >>>>>>>> HO. I guess the definition of the term depends on an >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> access tchnology or >>>>>> >>>>>> >>>>>> >>>>>>>> the >>>>>>>> combination of access technologies in the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> context of a use-case. >>>>>> >>>>>> >>>>>> >>>>>>>> -Raj >>>>>>>> >>>>>>>> >>>>>>>> On 6/29/09 4:36 PM, "ext Frank >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> Xia" wrote: >>>>>> >>>>>> >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Hi Raj >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> IMHO Make-before-break is not a link-layer technology. >>>>>> >>>>>> >>>>>> >>>>>>>>> , but a concept >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> (or a strategy). Related to the topic we >>>>>> >>>>>> >>>>>> >>>>>>>>> are discussing, making target >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> interface ready before moving >>>>>> >>>>>> >>>>>> >>>>>>>>> traffic to it is kind of >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> make-before-break. >>>>>> >>>>>> >>>>>> >>>>>>>>> BR >>>>>>>>> Frank >>>>>>>>> >>>>>>>>> ----- Original Message >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> ----- >>>>>> >>>>>> >>>>>> >>>>>>>>> From: >>>>>>>>> To: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> ; ; ; >>>>>> >>>>>> ; >>>>>> >>>>>> >>>>>> >>>>>>>>> Cc: ; >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>> Sent: Monday, June 29, 2009 3:43 PM >>>>>>>>> Subject: Re: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> [netext] [netlmm] NEXTEXT2: first draft of the bof >>>>>> >>>>>> description >>>>>> >>>>>> >>>>>> >>>>>>>>> Hi Frank, >>>>>>>>> >>>>>>>>> Comments >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> inline: >>>>>> >>>>>> >>>>>> >>>>>>>>> On 6/29/09 2:57 PM, "ext Frank Xia" >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> Raj >>>>>> >>>>>> >>>>>> >>>>>>>>>> My main point is make-before-break strategy >>>>>>>>>> is the best >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> way to solve multi-radio handover. >>>>>> >>>>>> >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> The IETF cannot >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> do anything about whether an MN has the ability to >>>>>> >>>>>> >>>>>> >>>>>>>>> accomplish >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> make-before-break connectivity. It depends on the link-layer >>>>>> >>>>>> >>>>>> >>>>>>>>> technology, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> spectrum that they operate in, etc. So this approach is a >>>>>> >>>>>> >>>>>> >>>>>>>>> non-starter. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> The IETF solution has to be agnostic to underlying access >>>>>> >>>>>> technologies. >>>>>> >>>>>> >>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Please see my inline >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> response. >>>>>> >>>>>> >>>>>> >>>>>>>>>> BR >>>>>>>>>> ----- Original Message ----- >>>>>>>>>> From: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>>> To: ; >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> ; ; >>>>>> >>>>>> >>>>>> >>>>>>>>>> ; >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>>> Cc: ; >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>>> Sent: Monday, June 29, 2009 11:50 AM >>>>>>>>>> Subject: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> Re: [netlmm] NEXTEXT2: first draft of the bof >>>>>> description >>>>>> >>>>>> >>>>>> >>>>>>>>>> Frank, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 6/29/09 11:16 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> AM, "ext Frank Xia" wrote: >>>>>> >>>>>> >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hi Guys >>>>>>>>>>> >>>>>>>>>>> I have comments on inter-technology >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> handover. >>>>>> >>>>>> >>>>>> >>>>>>>>>>> IMHO, flow mobility could solve problems >>>>>>>>>>> which >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> inter-tech handover is try to deal with. >>>>>> >>>>>> >>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Flow >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> mobility also includes the ability to move a flow from one mobility >>>>>> >>>>>> session to another. Multiple mobility sessions could be established via >>>>>> >>>>>> a >>>>>> >>>>>> >>>>>> >>>>>>>>>> single interface in which case flow mobility would be achieved >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> within >>>>>> >>>>>> >>>>>> >>>>>>>>>> the >>>>>>>>>> scope of a single interface. Hence flow mobility and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> inter-technology >>>>>> >>>>>> >>>>>> >>>>>>>>>> handovers are separate features. >>>>>>>>>> Frank=>IMHO, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> inter-technology is trying to move all the traffic on >>>>>> >>>>>> >>>>>> >>>>>>>>>> one interface to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> another interface. >>>>>> >>>>>> >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Right. I guess you answered the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> question about the difference between >>>>>> >>>>>> >>>>>> >>>>>>>>> flow >>>>>>>>> mobility and >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> inter-technology handovers. You could extrapolate and say >>>>>> >>>>>> >>>>>> >>>>>>>>> that >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> inter-technology HO is the case where you move all flows from one >>>>>> >>>>>> interface >>>>>> >>>>>> >>>>>> >>>>>>>>> to another and hence a variant of flow mobility. While that is >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> true, you >>>>>> >>>>>> >>>>>> >>>>>>>>> should also recognize that the granularity of flow mobility is >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> finer and >>>>>> >>>>>> >>>>>> >>>>>>>>> does not have to necessarily be a relocation of a flow between >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> physical >>>>>> >>>>>> >>>>>> >>>>>>>>> interfaces. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> I assume that two >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> heterogeneous interfaces are >>>>>> >>>>>> >>>>>> >>>>>>>>>>> all active during the handover. It is >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> easy to move >>>>>> >>>>>> >>>>>> >>>>>>>>>>> a flow(or all flows) from an interface to >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> another. >>>>>> >>>>>> >>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Possibly.. But the point is to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> identify what extensions (possibly to the >>>>>> >>>>>> >>>>>> >>>>>>>>>> MN) >>>>>>>>>> are needed in order >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> to achieve handovers across interfaces. >>>>>> >>>>>> >>>>>> >>>>>>>>>> Frank=>If we see inter-tech >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> handover as a subset of flow mobility, >>>>>> >>>>>> >>>>>> >>>>>>>>>> there is one problem left, that >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> is flow mobility. >>>>>> >>>>>> >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> See above. Flow mobility is a >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> feature that can work across multiple >>>>>> >>>>>> >>>>>> >>>>>>>>> mobility >>>>>>>>> sessions within the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> scope of a single interface as well. >>>>>> >>>>>> >>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> This is >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> probably the reason why there is no >>>>>> >>>>>> >>>>>> >>>>>>>>>>> inter-tech handover solution >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> standerdized >>>>>> >>>>>> >>>>>> >>>>>>>>>>> for client MIP. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Client >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> MIP inherently supports handovers across multiple interfaces. >>>>>> >>>>>> Performance improvements to the handovers are accomplished using >>>>>> >>>>>> solutions >>>>>> >>>>>> >>>>>> >>>>>>>>>> such as FMIP. >>>>>>>>>> Frank=>Maybe, I am missing something. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> However FMIP is not applicable >>>>>> >>>>>> >>>>>> >>>>>>>>>> to PAR/NAR collocated scenario. For >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> example, a mobile node with two >>>>>> >>>>>> >>>>>> >>>>>>>>>> interface connects to the same access >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> router (ASN-GW for WiMAX, >>>>>> >>>>>> >>>>>> >>>>>>>>>> PDN-GW for LTE). Does FMIP work when mobile >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> node handover from >>>>>> >>>>>> >>>>>> >>>>>>>>>> one technology to another? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Not sure I understand the question. In your example above, I believe >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> the >>>>>> >>>>>> >>>>>> >>>>>>>>> MN >>>>>>>>> would connect to the ASN-GW via the WiMAX interface and to an >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> S-GW via >>>>>> >>>>>> >>>>>> >>>>>>>>> the >>>>>>>>> LTE interface. The P-GW (LMA) may be the same. If the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> question is, can >>>>>> >>>>>> >>>>>> >>>>>>>>> you >>>>>>>>> use FMIP to optimize handovers in such a >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> scenario... Yes. Not FMIP, but >>>>>> >>>>>> >>>>>> >>>>>>>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> think we are looking at >>>>>> >>>>>> >>>>>> >>>>>>>>> optimizing >>>>>>>>> handovers in this >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> discussion. >>>>>> >>>>>> >>>>>> >>>>>>>>> As per the current PMIP6 specification wherein no changes to >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> the host are >>>>>> >>>>>> >>>>>> >>>>>>>>> required, it is not possible to do an inter-technology >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> handover. This is >>>>>> >>>>>> >>>>>> >>>>>>>>> a >>>>>>>>> limitation which implies that PMIP6 provides >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> host mobility to an MN >>>>>> >>>>>> >>>>>> >>>>>>>>> within >>>>>>>>> the scope of a single access >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> technology. Host based mobile IP does not >>>>>> >>>>>> >>>>>> >>>>>>>>> have >>>>>>>>> this >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> problem. >>>>>> >>>>>> >>>>>> >>>>>>>>> -Raj >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -Raj >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> BR >>>>>>>>>>> Frank >>>>>>>>>>> >>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> From: "marcelo bagnulo braun" >>>>>> >>>>>> >>>>>> >>>>>>>>>>> To: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> ; "mext" ; >>>>>> >>>>>> >>>>>> >>>>>>>>>>> Cc: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> ; "Ralph Droms" >>>>>> >>>>>> >>>>>> >>>>>>>>>>> Sent: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> Sunday, June 28, 2009 1:16 PM >>>>>> >>>>>> >>>>>> >>>>>>>>>>> Subject: [netlmm] NEXTEXT2: first draft >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> of the bof description >>>>>> >>>>>> >>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> This is a first draft of the BOF description for your >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> consideration. >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> It >>>>>>>>>>>> is >>>>>>>>>>>> still very open so, feel free to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> comment on whether the proposed >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> approach >>>>>>>>>>>> seems appropriate or >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> not. >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> NETEXT2 BOF description >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> ----------------------- >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> a network based mobility >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> protocol built on Mobile IPv6 [RFC3775]. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> PMIP6 provides mobility to >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> IP hosts without requiring any protocol >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> enhancements or additional >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> capabilities on the host. >>>>>>>>>>>> Current >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> PMIP6 specification fully defines how to provide mobility >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> support for >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> mobile nodes with a single interface roaming in a PMIP6 >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> domain. The >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> goal of this BOF is gain understanding of how to support >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> nodes with >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> multiple interfaces (of possible different technologies) in >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> PMIP6 network. >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> In particular, this BOF assumes the following >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> scenario: >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> We have a single PMIP6 domain that has deployed >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> multiple >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> access technologies and needs to support nodes that >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> have >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> multiple interfaces, possibly of different >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> technologies. >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> In particular, the following capabilities are >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> needed: >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> - Inter-technology handover support. The MN has >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> initiated a >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> communication over one interface and it needs to be able >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> to move >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> the established connection to a different interface of >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> a possibly different technology. The reason for moving >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> communication to another interface is because of the MNs >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> mobility and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> attaching via a different interface. Basically >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> the ability to perform >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> handovers that span different access >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> technologies. >>>>>>>>>>>> >>>>>>>>>>>> - >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> Multihoming support. The MN with multiple interfaces of possibly >>>>>> >>>>>> different technologies should be able to use them simultaneously to >>>>>> >>>>>> exchange data and manage the mobility of communications >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> established >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> through the different interfaces. >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> - Flow mobility. A MN with >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> multiple interfaces of possibly >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> different technologies must be able to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> move a flow from >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> one interface to another. Moreover, the MN should be >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> able >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> to inform the network through which interface it wishes >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> to receive different types of flows. >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> In order to provide the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> support for these capabilities, different >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> approaches can be >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> envisioned, namely: >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> - L2 only approaches. In this type of approaches, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> the mechanisms >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> to provide the required capabilities are fully L2 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> mechanisms and >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> no modification of the IP layer is needed. >>>>>>>>>>>> - L3 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> only approaches. In this type of approaches, the mechanism to >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> provide >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> to required capabilities are located in the IP layer >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> - Hybrid L2/L3 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> approaches. In this case, some mechanisms are >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> located in L2 and other >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> mechanisms are located in L3. >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> Now, the different possible approaches >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> vary greatly in their nature >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> and resulting capabilities. To >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> understanding the benefits and >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> suitability of these alternatives, the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> requirements have to be >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> properly defined and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> understood. >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> The main goal of the BOF is understanding the need >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> for work in the >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> IETF in this area. In order to do so, during the BOF, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> we will attempt >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> to: >>>>>>>>>>>> >>>>>>>>>>>> 1) Understand the applicable >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> scenarios, and the problem statement >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> related >>>>>>>>>>>> to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> those >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> 2) Understand the restrictions and requirement imposed to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> solutions to >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> address the problem statement and scenarios >>>>>>>>>>>> 3) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> Get an overview of the proposed solutions >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> netlmm mailing >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> list >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> netlmm@ietf.org >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> https://www.ietf.org/mailman/listinfo/netlmm >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> netext mailing >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> list >>>>>> >>>>>> >>>>>> >>>>>>>>>> netext@ietf.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>> >>>>>> >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> >>>>>> >>>>>>>> MEXT mailing list >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> MEXT@ietf.org >>>>>> >>>>>> >>>>>> >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> MEXT@ietf.org >>>>>> >>>>>> >>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> netlmm mailing list >>>>>> >>>>>> netlmm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netlmm >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> netlmm mailing >>>>> >>>>> >>>>> >>>>>> list >>>>>> >>>>>> >>>>>> >>>>> netlmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netlmm >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > > > From Marco.Liebsch@nw.neclab.eu Tue Jun 30 10:06:26 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6A0828C42A; Tue, 30 Jun 2009 10:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] 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 lsrzI4wHYRw8; Tue, 30 Jun 2009 10:06:25 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2134E3A6A3E; Tue, 30 Jun 2009 10:06:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id C4AC42C00C51C; Tue, 30 Jun 2009 17:38:00 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JarY01huqImg; Tue, 30 Jun 2009 17:38:00 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 914932C020493; Tue, 30 Jun 2009 17:37:25 +0200 (CEST) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Jun 2009 17:37:25 +0200 Message-ID: <4A4A3135.7060105@nw.neclab.eu> Date: Tue, 30 Jun 2009 17:37:25 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Frank Xia References: <4A47B36B.9030702@it.uc3m.es> <000e01c9f8d4$ff2bde30$3e0c7c0a@china.huawei.com> <001401c9f8dd$d6c16830$3e0c7c0a@china.huawei.com> <853DD750D9C3724FBF2DF7164FCF641C032776AE@FRVELSMBS14.ad2.ad.alcatel.com> <004b01c9f8f7$56779d60$3e0c7c0a@china.huawei.com> In-Reply-To: <004b01c9f8f7$56779d60$3e0c7c0a@china.huawei.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 30 Jun 2009 15:37:25.0882 (UTC) FILETIME=[AB2ABDA0:01C9F998] Cc: netext@ietf.org, netext-chairs@tools.ietf.org, MELIA TELEMACO , netlmm@ietf.org, mext Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof description X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 17:06:26 -0000 Frank, Frank Xia wrote: > Hi Telemaco > > There are three use cases in my mind: > > 1)Two interfaces are active at the same time. > > This is the most common case. Flow mobility > can handle all the problems relating to handover. > > 2)One interafce is active while the other is dormant. > > The dormant interface is activated before handover. > Flow mobility can also do with it. > > 3)One interafce is active while the other is dormant, and > traffic must be offloaded from the active one even though > the dormant one is not ready. > > This is a rare case. If "inter-technology handover" > focuses on dealing with this scenario, I am fine. Still inter-tech handover is different from flow mobility. Also complexity-wise. For inter-technology handover the mobile may only provide hints about the nature of the handover (inter-tech HO etc), maybe about handover target or source to the network. If you want flow mobility, you need to handle flow descriptions and signal appropriate filters, hence much more to be done by the mobile and by the network. Not sure the PMIPv6 protocol should handle flow filters.. If you move all flows during a handover, we're back at inter-tech handover, say we move the complete mobility session with the intention to shut down the previous mobility session (and with mobility session I mean the MN's binding between the HNP and the pMAG at the LMA). Moving the associated flows is implicit. Hence, requirement on the mobile is very different for flow mobility and inter-tech handover (shouldn't we say dual radio handover here?) marco > > BR > Frank > > ----- Original Message ----- From: "MELIA TELEMACO" > > To: "Frank Xia" ; "George Tsirtsis" > > Cc: ; ; > ; "mext" > Sent: Monday, June 29, 2009 1:03 PM > Subject: RE: [netlmm] [MEXT] NEXTEXT2: first draft of the bof description > > > Frank, > > I think you should not mix flow mobility and inter-tech handover. A MN > might or might now use multiple connections at the same time... > > telemaco > > -----Message d'origine----- > De : netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] De la > part de Frank Xia > Envoyé : lundi 29 juin 2009 19:20 > À : George Tsirtsis > Cc : netext@ietf.org; netlmm@ietf.org; netext-chairs@tools.ietf.org; mext > Objet : Re: [netlmm] [MEXT] NEXTEXT2: first draft of the bof description > > Hi Gorge > > It seems that I did not make me clear. > > 1)Single radio handover. > MN should disconnect from one BS , and connect > to a second BS. MN can't connect to the two BS > at the same time. Handover solutions (FMIP/PMIP) > are needed. > > 2)Dual radio handover > MN connects to the two BS' at the same time. > Flow mobility is sufficient when move a flow( or all > flows) from one interface to another. > > BR > Frank > > ----- Original Message ----- From: "George Tsirtsis" > > To: "Frank Xia" > Cc: "marcelo bagnulo braun" ; ; > "mext" > ; ; > Sent: Monday, June 29, 2009 11:48 AM > Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof description > > > Frank, your comment below is strange to say the least. > > MIP handoffs can be between interfaces of the same or different > technologies. Since client MIP works at the IP layer (above the Link > Layer of any specific technology) there is nothing that client MIP > (and any of its features) need to specifically define for > inter-technology handoffs. > > >Did you so far think that this means that client MIP only works > intra-technology?< > > For PMIP, this is an issue because currently there is no defined > protocol (on any layer) between MN and MAG...which is one of the > issues to be discussed in netext2 bof. > > George > > On Mon, Jun 29, 2009 at 5:16 PM, Frank Xia wrote: >> Hi Guys >> >> I have comments on inter-technology handover. >> >> IMHO, flow mobility could solve problems >> which inter-tech handover is try to deal with. >> I assume that two heterogeneous interfaces are >> all active during the handover. It is easy to move >> a flow(or all flows) from an interface to another. >> >> This is probably the reason why there is no >> inter-tech handover solution standerdized >> for client MIP. >> >> BR >> Frank >> >> ----- Original Message ----- From: "marcelo bagnulo braun" >> >> To: ; "mext" ; >> Cc: ; "Ralph Droms" >> Sent: Sunday, June 28, 2009 1:16 PM >> Subject: [netlmm] NEXTEXT2: first draft of the bof description >> >> >>> Hi, >>> >>> This is a first draft of the BOF description for your consideration. It >>> is >>> still very open so, feel free to comment on whether the proposed >>> approach >>> seems appropriate or not. >>> >>> NETEXT2 BOF description >>> ----------------------- >>> >>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility >>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to >>> IP hosts without requiring any protocol enhancements or additional >>> capabilities on the host. >>> Current PMIP6 specification fully defines how to provide mobility >>> support for mobile nodes with a single interface roaming in a PMIP6 >>> domain. The goal of this BOF is gain understanding of how to support >>> nodes with multiple interfaces (of possible different technologies) >>> in a >>> PMIP6 network. >>> >>> In particular, this BOF assumes the following scenario: >>> We have a single PMIP6 domain that has deployed multiple >>> access technologies and needs to support nodes that have >>> multiple interfaces, possibly of different technologies. >>> >>> In particular, the following capabilities are needed: >>> >>> - Inter-technology handover support. The MN has initiated a >>> communication over one interface and it needs to be able to move >>> the established connection to a different interface of >>> a possibly different technology. The reason for moving >>> the communication to another interface is because of the MNs >>> mobility and attaching via a different interface. Basically >>> the ability to perform handovers that span different access >>> technologies. >>> >>> - Multihoming support. The MN with multiple interfaces of possibly >>> different technologies should be able to use them simultaneously to >>> exchange data and manage the mobility of communications >>> established through the different interfaces. >>> >>> - Flow mobility. A MN with multiple interfaces of possibly >>> different technologies must be able to move a flow from >>> one interface to another. Moreover, the MN should be able >>> to inform the network through which interface it wishes >>> to receive different types of flows. >>> >>> In order to provide the support for these capabilities, different >>> approaches can be envisioned, namely: >>> - L2 only approaches. In this type of approaches, the mechanisms >>> to provide the required capabilities are fully L2 mechanisms and >>> no modification of the IP layer is needed. >>> - L3 only approaches. In this type of approaches, the mechanism to >>> provide to required capabilities are located in the IP layer >>> - Hybrid L2/L3 approaches. In this case, some mechanisms are >>> located in L2 and other mechanisms are located in L3. >>> Now, the different possible approaches vary greatly in their nature >>> and resulting capabilities. To understanding the benefits and >>> suitability of these alternatives, the requirements have to be >>> properly defined and understood. >>> >>> The main goal of the BOF is understanding the need for work in the >>> IETF in this area. In order to do so, during the BOF, we will >>> attempt to: >>> >>> 1) Understand the applicable scenarios, and the problem statement >>> related >>> to >>> those >>> 2) Understand the restrictions and requirement imposed to solutions to >>> address the problem statement and scenarios >>> 3) Get an overview of the proposed solutions >>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/netlmm >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm From trac@tools.ietf.org Tue Jun 30 11:00:44 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68363A6C5B for ; Tue, 30 Jun 2009 11:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 KPL1NGbZIzDR for ; Tue, 30 Jun 2009 11:00:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id C4EE03A6A19 for ; Tue, 30 Jun 2009 11:00:43 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MLhdg-0007IJ-BU; Tue, 30 Jun 2009 11:01:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "Mext Issue Tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Tue, 30 Jun 2009 18:01:04 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mext/trac/ticket/18#comment:2 Message-ID: <066.2d589ef03a5b6cff841c62c855b3a58e@tools.ietf.org> References: <057.593245298a70f232e7c46117adba47bb@tools.ietf.org> X-Trac-Ticket-ID: 18 In-Reply-To: <057.593245298a70f232e7c46117adba47bb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #18: Subject: Issues regarding Home Address Option & ICMP / Binding errors X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 18:00:44 -0000 #18: Subject: Issues regarding Home Address Option & ICMP / Binding errors ----------------------------------------+----------------------------------- Reporter: f1mauchl@hsr.ch | Owner: charliep@computer.org Type: defect | Status: closed Priority: minor | Milestone: IETF75 Component: draft-ietf-mext-rfc3775bis | Version: 4.0 Severity: Active WG Document | Resolution: fixed Keywords: Home Agent Binding Error | ----------------------------------------+----------------------------------- Changes (by charliep@computer.org): * keywords: Home Address Option => Home Agent Binding Error * priority: major => minor * status: assigned => closed * resolution: => fixed Comment: >> In Section 11.3.6. Receiving Binding Error Messages, it is not >> considered that Binding Error Messages can also come from Home >> Agents when acting as a Correspondent Node to its Mobile Nodes >> [see also issue #12]. ......... >> If the Correspondent Node is the Home Agent, it is likely that >> there is also no tunnel to route communications through. This >> case may happen if the Home Agent reboots without a persistent >> storage of its Binding Cache. Scenario for failure case: * Suppose the MN has successfully bound to its HA. * Now the HA crashes, losing all of its Binding Cache and Tunnel information. This means that the Tunnel to the MN is now invalid. Any further packets sent thru the tunnel will be dropped at the HA. * The MN now starts a direct communication with the HA. (e.g. the user pings the HA to check if it's alive). As the MN still has a Binding Update List entry with the corresponding addresses, it will add a HAO to the packet and send it directly to the HA. * Upon reception, the HA checks the HAO and will not find a matching Binding Cache entry and return a Binding Error. * According to 11.3.6, the MN should now use the Tunnel, which is still invalid. Proposal: Add the following as the first bullet in section 11.3.6: >> o If the Binding Error Message was sent by the Home Agent, >> the Mobile Node SHOULD send a Binding Update to the Home Agent >> according to Section 11.7.1. -- Ticket URL: mext From trac@tools.ietf.org Tue Jun 30 11:18:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0C2D3A6BCE for ; Tue, 30 Jun 2009 11:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 edoej03ucLEX for ; Tue, 30 Jun 2009 11:18:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id E3C7E3A67FF for ; Tue, 30 Jun 2009 11:18:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MLhul-0001JO-Hm; Tue, 30 Jun 2009 11:18:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "Mext Issue Tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Tue, 30 Jun 2009 18:18:43 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mext/trac/ticket/18#comment:3 Message-ID: <066.a93a8ef0fb9cf3d4dafb2a55311686f3@tools.ietf.org> References: <057.593245298a70f232e7c46117adba47bb@tools.ietf.org> X-Trac-Ticket-ID: 18 In-Reply-To: <057.593245298a70f232e7c46117adba47bb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #18: Subject: Issues regarding Home Address Option & ICMP / Binding errors X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 18:18:25 -0000 #18: Subject: Issues regarding Home Address Option & ICMP / Binding errors ----------------------------------------+----------------------------------- Reporter: f1mauchl@hsr.ch | Owner: charliep@computer.org Type: defect | Status: reopened Priority: minor | Milestone: IETF75 Component: draft-ietf-mext-rfc3775bis | Version: 4.0 Severity: Active WG Document | Resolution: Keywords: ICMP Parameter Problem | ----------------------------------------+----------------------------------- Changes (by charliep@computer.org): * keywords: Home Agent Binding Error => ICMP Parameter Problem * status: closed => reopened * resolution: fixed => Comment: Receiving ICMP Errors [Fabian Mauchle ] Proposed resolution: do not make any changes to existing specification in response to this issue regarding handling of ICMP Parameter Problem Issue #18, part 2 of 3: > Some questions arose whether to treat ICMP Parameter Error messages or > to ignore them. In Section 11.3.6. Receiving Binding Error Messages: > "If the mobile node receives such an ICMP error message (Code 1) in > response to a return routability procedure or Binding Update,..." > The following situations are not clear or problematic: > 1.) If the Mobile Node did not set the Acknowledge bit in the Binding > Update, should it also accept an ICMP Parameter Problem, Code 1 > and during which period of time? > 2.) If the ICMP message came from a Home Agent, it is most likely to > be a spoofed message since packets to the Home Agent nearly always > contain a Home Address Option, which would cause an ICMP Parameter > Problem, Code 2 instead. A Mobile Node MUST therefore ignore any > ICMP Parameter Problem messages originating from a Home Agent, > otherwise, an attacker could prevent a Mobile Node from sending > Binding Updates to its Home Agent. > Proposal for 2.): Add to the first paragraph in 11.3.6: > If the source of the ICMP error message is a Home Agent, > it MUST be ignored. Three discussion points [Brian Haley ]: >> What do to with ICMP Parameter Problem, Code 0 ...? > It's defined in RFC 4443: > A node receiving this ICMPv6 message MUST notify the upper-layer > process if the relevant process can be identified (see Section 2.4, > (d)). and: > The question is whether having the MN drop all ICMP param problems from the HA > is better or worse than the very small possibility that someone can disrupt > mobility. I would vote for leaving the text alone and: > Protecting ICMP errors would require new IPsec SPDs, which I don't think is > feasible. -- Ticket URL: mext